# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # У У У У # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Aflați fabricarea instrumentelor PowerShell într-o lună de prânz DON JONES JEFFERY HICKS MAN NI NG Insula Adăpostului Pentru informații online și pentru comandarea acestei cărți și a altor cărți Manning, vă rugăm să vizitați www manning com Editorul oferă reduceri la această carte atunci când este comandată în cantitate Pentru mai multe informații, vă rugăm contactați Departament special de vânzări Manning Publications Со Baldwin Road Căsuța poștală Shelter Island, NY E-mail: orders@manning com © de către Manning Publications Со Toate drepturile rezervate Nicio parte a acestei publicații nu poate fi reprodusă, stocată într-un sistem de recuperare sau transmisă, sub nicio formă sau prin mijloace electronice, mecanice, prin fotocopiere sau în alt mod, fără permisiunea prealabilă scrisă a editorului Multe dintre denumirile folosite de producători și vânzători pentru a-și distinge produsele sunt revendicate ca mărci comerciale Acolo unde acele denumiri apar în carte și Manning Publications cunoștea o revendicare a unei mărci comerciale, denumirile au fost tipărite cu majuscule inițiale sau cu majuscule Recunoscând importanța păstrării a ceea ce a fost scris, este politica lui Manning să tipărim cărțile pe care le publicăm pe hârtie fără acid și depunem toate eforturile în acest scop Recunoscând și responsabilitatea noastră de a conserva resursele planetei noastre, cărțile Manning sunt tipărite pe hârtie care este reciclată și procesată în proporție de cel puțin % fără utilizarea clorului elementar ■Л Manning Publications Со Baldwin Road PO Box ■Л Manning Publications Со Baldwin Road PO Box Shelter Island, NY Shelter Island, NY Development editor: Technical proofreader: Copyeditor: Proofreader: Typesetter: Cover designer: Development editor: Technical proofreader: Copyeditor: Proofreader: Typesetter: Cover designer: Cynthia Капе James Berkenbile Linda Recktenwald Maureen Spencer Gordan Salinovic Leslie Haimes Cynthia Капе James Berkenbile Linda Recktenwald Maureen Spencer Gordan Salinovic Leslie Haimes ISBN Tipărit în Statele Unite ale Americii - MAL- Înainte de a începe Prezentare generală a scripturilor PowerShell Limbajul de scripting PowerShell Scripturi și funcții simple Domeniul de aplicare Ghid de proiectare a sculelor Funcții avansate, partea Funcții avansate, partea Ajutor la scriere Gestionarea erorilor Tehnici de depanare Crearea vizualizărilor de format personalizate Module de script și manifest Adăugarea accesului la baza de date Interludiu: crearea unui nou instrument Efectuarea de instrumente care efectuează modificări Crearea unei extensii de tip personalizat Crearea fluxurilor de lucru PowerShell Depanarea intrării în conductă Utilizarea ierarhiilor de obiecte pentru ieșirea complexă Globalizarea unei funcții Trecerea liniei: utilizarea NET Framework Crearea unui instrument GUI, partea : GUI Crearea unui instrument GUI, partea : codul Crearea unui instrument GUI, partea : ieșirea Crearea funcțiilor proxy Configurarea punctelor finale constrânse la distanță Niciodată la sfârșit prefață хи despre această carte xvi despre autori xix mulțumiri xx Ce este fabricarea de unelte? Aceasta carte este pentru tine? Cerințe preliminare PowerShell v Privilegii Admira Mai multe computere SQL Server PowerShell ISE Cerințe preliminare opționale Cum se utilizează această carte Ce este scriptingul PowerShell? Politica de execuție a PowerShell Rularea scripturilor Editarea scripturilor Explorări suplimentare: editori de scripturi Laboratorul Un script, o conductă Variabile Ghilimele Membrii și variabilele obiectului Paranteze Reîmprospătare: comparații Construcții logice Dacă construcția Comutați construcția Construcții în buclă Faceți În timp ce construiți Pentru fiecare construcție Pentru constructul Rupeți și continuați în constructele Laboratorul Începeți cu o comandă Transformați comanda într-un script Parametrizați comanda Transformați scriptul într-o funcție Testarea funcției D otsourcing Apelarea funcției în script Abetterway ahead: module Laboratorul Ce scop? Vederea domeniului de aplicare în acțiune Lucrări în afara domeniului de aplicare Devenind strict cu domeniul de aplicare Cele mai bune practici pentru domeniul de aplicare Laboratorul Fă un lucru și fă-l bine Instrumente de intrare Instrumente funcționale Instrumente de ieșire Laboratoarele LabA LabB Lab C Șablon de funcție avansată Proiectarea funcției Declararea parametrilor Testarea parametrilor Scrierea codului principal Ieșirea obiectelor personalizate Ce să nu faci Urmează următorul Laboratoarele Laborator A Laborator В Laborator C Laborator autonom Facerea parametrilor obligatorii Ieșire verbală Aliasuri de parametri Se acceptă intrarea conductei Validarea parametrilor Adăugarea unui parametru comutator Ajutor pentru parametri Urmează următorul Laboratoarele LabA LabB Lab C Lab autonom Ajutor bazat pe comentarii Ajutor bazat pe XML Urmează următorul Laboratoarele Laboratorul A Laboratorul Laboratorul C Laboratorul autonom Totul ține de acțiune Setarea acțiunii de eroare Salvarea erorii Gestionarea erorilor vl: Capcană Gestionarea erorilor v +: Încercați Prinde În sfârșit Furnizarea unor imagini vizuale Urmează următorul Laboratoarele Lab A LabB Lab C Lab autonom Două tipuri de bug-uri Rezolvarea greșelilor de scriere Trucul adevărat pentru depanare: așteptări Tratarea erorilor logice: codul de urmărire Tratarea erorilor logice: puncte de întrerupere Serios, ai așteptări Următorul Laboratorul Anatomia unei vederi Adăugarea unui nume de tip la obiectele de ieșire Realizarea vizualizării Încărcarea și depanarea vizualizării Utilizarea vizualizării Următorul Laboratoarele LabA LabB Lab C Introducerea modulelor Locația modulului Numele modulului Conținutul modulului Crearea unui modul de script Crearea unui manifest de modul Crearea unei variabile de setare la nivel de modul Urmează următorul Laboratorul LabA LabB Lab C Simplificarea accesului la baza de date Configurarea mediului dvs Funcțiile bazei de date Despre funcțiile bazei de date Utilizarea funcțiilor bazei de date Laboratorul Proiectarea instrumentului Scrierea și testarea funcției Îmbrăcarea parametrilor Adăugarea ajutorului Gestionarea erorilor Realizarea unui modul Urmează următorul Parametrii-Confirmare și-Whatlf Passthrough ShouldProcess Definirea nivelului de impact Implementarea ShouldProcess Laboratorul Anatomia unei extensii Crearea unei proprietăți de script Crearea unei metode de script Se încarcă extensia Testarea extensiei Adăugarea extensiei la un manifest Laboratorul Prezentare generală a fluxului de lucru Parametri comuni pentru fluxurile de lucru Activități și execuție apatridă Starea Perși sting Suspendarea și reluarea fluxurilor de lucru Inerent la distanță Paralelism Strategia generală de proiectare a fluxului de lucru Exemplu de scenariu de flux de lucru Scrierea fluxului de lucru Fluxuri de lucru vs funcții Laboratorul Actualizare: cum funcționează introducerea canalului Vă prezentăm Trace-Command Interpretarea ieșirii comenzii de urmărire Laboratorul Când ar putea fi necesară o ierarhie Ierarhii și CSV: nu este o idee bună Crearea obiectelor imbricate Lucrul cu obiecte imbricate Folosirea Select-Object pentru a extinde obiecte copil Utilizarea Format-Custom pentru a extinde o ierarhie de obiecte Folosirea unei bucle ForEach pentru a enumera subobiecte Utilizarea sintaxei matrice a lui PowerSheU pentru a accesa subobiecte individuale Laboratorul Introducere în globalizare Limbajul de date PowerShell Stocarea șirurilor traduse Trebuie să te globalizezi? Laboratorul Clase și instanțe NET Metode statice ale clasei Instanțierea unei clase Folosind Reflection Găsirea documentației de clasă PowerShell vs Visual Studio Laboratorul Introducere în WinForms Utilizarea unei GUI pentru a crea GUI Codarea manuală a GUI Se afișează GUI Laboratorul Adresarea obiectelor GUI Exemplu: casetele de text Exemplu: clicuri pe buton Exemplu: casetele cu listă Exemplu: butoanele radio Exemplu: casetele de selectare Laboratorul Utilizarea Out-GridView Crearea unui formular pentru ieșirea Popularea și afișarea ieșirii Laboratorul Ce sunt funcțiile proxy? Crearea șablonului funcției proxy Eliminarea unui parametru Adăugarea unui parametru Încărcarea funcției proxy Laboratorul Actualizare: Arhitectura de la distanță Ce sunt punctele finale constrânse? Crearea definiției punctului final Înregistrarea punctului final Conectarea la punctul final Laboratorul Bun venit la fabricarea de unelte Idei interesante pentru instrumente Care este următorul tău pas? anexa tehnologii GUI și PowerShell index Am o perspectivă unică asupra scenariilor În prima mea carieră ca mecanic de avioane, am lucrat cu mașiniști – oameni care foloseau unelte și matrițe pentru a sculpta metal în piesele aeronavei Un pas deasupra mașinistului, din punct de vedere al carierei, a fost producătorul de scule și matrițe Aceștia au fost oameni cu înaltă pregătire care au creat de fapt uneltele și matrițele folosite de mașiniști Oamenii aspirau să fie producători de unelte, așa cum erau porecți, pentru că era considerată o slujbă puțin mai confortabilă Nu ai lucrat pe podeaua fierbinte în jurul mașinilor care țipă și cioburilor zburătoare; ai lucrat într-un birou cool, la o stație de proiectare asistată de computer (CAD) Ai purtat haine mai frumoase Se pare că PowerShell poate fi tratat aproape în același mod Imaginați-vă că lucrați într-un birou frumos și cool, fără utilizatori care să vă solicite atenția Navigați prin sistemul de bilete al biroului de asistență al organizației dvs , căutând probleme recurente care consumă mult timp sau care ajung să fie rezolvate de personalul tehnic de nivel superior Scrieți instrumente, în PowerShell, pentru a rezolva aceste probleme Implementați aceste instrumente la biroul de asistență și la colegii dvs de nivel inferior Acum pot rezolva acele probleme mai rapid și mai consecvent - și cu mai puțină implicare din partea dvs Slujba ta este mai confortabilă Poate ești și tu plătit mai mult Sună grozav, nu? Se va întâmpla Același model s-a repetat, iar și iar, de-a lungul istoriei IT-ului, în aproape fiecare colț al IT, cu excepția spațiului Microsoft, în principal pentru că nu am avut instrumentele potrivite pentru crearea instrumentelor Ei bine, facem acum: Windows PowerShell Dacă sunteți gata să nu mai gândiți ca un buton-click și comand-runner și să începeți să gândiți ca un producător de unelte, ați luat cartea potrivită DonJones Cele mai multe dintre ceea ce trebuie să știți despre această carte sunt tratate în capitolul , dar există câteva lucruri pe care ar trebui să le menționăm înainte În primul rând, dacă intenționați să urmați exemplele noastre și să finalizați exercițiile practice, veți avea nevoie de o mașină virtuală sau un computer care rulează Windows sau Windows Server Vom acoperi acest lucru mai detaliat în capitolul vă puteți descurca cu Windows , dar veți pierde câteva dintre laboratoarele practice În al doilea rând, fiți pregătiți să citiți această carte de la început până la sfârșit, acoperind fiecare capitol în ordine Din nou, acesta este ceva pe care îl vom explica mai detaliat în capitolul , dar ideea este că fiecare capitol introduce câteva lucruri noi de care veți avea nevoie în capitolele următoare Nu ar trebui să încercați să depășiți întreaga carte - rămâneți cu abordarea unui capitol pe zi Creierul uman poate absorbi doar atâtea informații deodată și, luând PowerShell în bucăți mici, îl vei învăța mult mai rapid și mai amănunțit În al treilea rând, această carte conține o mulțime de fragmente de cod Cele mai multe dintre ele sunt destul de scurte, așa că ar trebui să le puteți tasta cu ușurință De fapt, vă recomandăm să le introduceți, deoarece acest lucru va ajuta la consolidarea unei abilități esențiale PowerShell: tastarea precisă! Fragmente de cod mai lungi sunt date în liste și sunt disponibile pentru descărcare la (doar faceți clic pe imaginea de copertă a acestei cărți și căutați secțiunea „Descărcări”) Acestea fiind spuse, există câteva convenții de care ar trebui să fii conștient Codul va apărea întotdeauna într-un font special, la fel ca în acest exemplu: Get-WmiObject -class Win OperatingSystem -computerName SERVER-R Acest exemplu ilustrează, de asemenea, caracterul de continuare al rândului folosit în această carte Indică faptul că acele două linii ar trebui de fapt tastate ca o singură linie în PowerShell Cu alte cuvinte, nu apăsați pe Enter sau Return după Win OperatingSystem - continuați să tastați PowerShell permite rânduri foarte lungi, dar paginile acestei cărți pot conține doar atât de mult Uneori, veți vedea și fontul codului în textul în sine, cum ar fi atunci când scriem Get-Command Acest lucru vă permite să știți că vă uitați la o comandă, un parametru sau un alt element pe care l-ați introduce în shell Al patrulea este un subiect complicat pe care îl vom aduce din nou în mai multe capitole: caracterul backtick (') Iată un exemplu: Invoke-Command -scriptblock { Dir } -computerName SERVER-R ,localhost Caracterul de la sfârșitul primului rând nu este un pic de cerneală rătăcită - este un caracter real pe care l-ai tasta Pe o tastatură din SUA, backtick-ul (sau accentul grav) este de obicei în partea din stânga sus, sub tasta Escape, pe aceeași tastă cu caracterul tilde (~) Când vedeți backtick într-o listă de cod, introduceți-l exact așa cum este În plus, atunci când apare la sfârșitul unei linii - ca în exemplul precedent - asigurați-vă că este ultimul caracter de pe acea linie Dacă permiteți să apară spații sau file după el, backtick-ul nu va funcționa corect și nici exemplul de cod Sincer, ar fi mai ușor să descărcați exemplele de cod și să nu vă faceți griji să le introduceți Sunt postate la - doar faceți clic pe imaginea de copertă a acestei cărți și mergeți la secțiunea Descărcări De asemenea, puteți descărca codul de pe site-ul web al editorului la În cele din urmă, ocazional vă vom direcționa către resursele de internet Acolo unde acele adrese URL sunt deosebit de lungi și dificil de tastat, le-am înlocuit cu URL-uri prescurtate bazate pe Manning, care arată ca (veți vedea pe aceea în capitolul ) Achiziționarea Learn PowerShell Toolmaking într-o lună de prânz include accesul la un forum privat condus de Manning Publications unde puteți face comentarii despre carte, pune întrebări tehnice și primi ajutor de la autori și alți utilizatori Pentru a accesa și a vă abona la forum, îndreptați browserul către și faceți clic pe linkul Autor online Această pagină oferă informații despre cum să intri pe forum odată ce te-ai înregistrat, ce fel de ajutor este disponibil și regulile de conduită pe forum Angajamentul lui Manning față de cititorii noștri este de a oferi un loc unde poate avea loc un dialog semnificativ între cititorii individuali și între cititori și autori Nu este un angajament pentru o anumită sumă de participare din partea autorilor, a căror contribuție la forumul cărții rămâne voluntară (și neplătită) Vă sugerăm să încercați să puneți autorilor câteva întrebări provocatoare, ca nu cumva să le rătăcească interesul! Forumul Autor Online și arhivele discuțiilor anterioare vor putea fi accesate de pe site-ul editurii atâta timp cât cartea se află în tipar Don Jones a primit pe mai mulți ani premiul Microsoft cel mai valoros profesionist (MVP) pentru munca sa cu Windows PowerShell Nu scrie coloana Windows PowerShell pentru Microsoft TechNet Magazine, bloguri la PowerShell org și scriu coloana „Decision Maker” și blogul pentru Redmond Magazine Don este un autor pro lific de tehnologie și a publicat peste o duzină de cărți prinț din Don este partener principal și tehnolog principal pentru Tehnologia concentrată (ConcentratedTech com), o firmă de educație IT și consultanță strategică Primul limbaj de scripting pentru Windows al lui Don a fost KiXtart, plecând până la mijlocul anilor Nu am absolvit rapid VBScript în și a fost unul dintre primii profesioniști IT care a început să folosească versiunile timpurii ale unui nou produs Microsoft, numit de cod „Monad”, care mai târziu a devenit Windows PowerShell Don locuiește în Las Vegas și călătorește în toată lumea, oferind cursuri IT (în special în PowerShell) și vorbind la conferințe IT Jeffery Hicks este un MVP Microsoft pe mai mulți ani în Windows PowerShell, un formator certificat Microsoft și un veteran IT cu de ani de experiență, o mare parte din ea petrecută ca consultant IT specializat în tehnologiile de server Microsoft Nu lucrează astăzi ca autor independent, trainer și consultant cu clienți din întreaga lume Jeff scrie coloana populară Prof PowerShell pentru MPCMag com și este un colaborator regulat la baza de cunoștințe Petri IT Dacă nu scrie cărți, atunci cel mai probabil înregistrează videoclipuri de formare pentru companii precum TrainSignal sau ajută în forumurile de discuții Puteți ține pasul cu Jeff pe blogul său, Cărțile pur și simplu nu scriu, editează și publică singure Don ar dori să mulțumească tuturor celor de la Manning Publications care au decis să-și asume o șansă cu un alt tip de carte pentru Windows PowerShell și care au muncit atât de mult pentru ca această carte să se realizeze Și Jeff ar dori să-i mulțumească lui Don pentru că l-a invitat la călătorie, precum și comunității PowerShell pentru entuziasm și sprijin Suntem amândoi recunoscători lui Manning pentru că ne-a permis să continuăm seria „Luna de prânz” cu următoarea carte în linie Mulțumim, de asemenea, următorilor evaluatori care au citit manuscrisul în timpul dezvoltării sale și au oferit feedback: Bryan Clark, Chad McAuley, Christoph Tohermes, David Smith, Karl Mitschke, Manuel Ruf, Marc Johnson, Mark Schill, Mike Stevenson, Nathan Shelby și Thomas Lee Mulțumiri speciale lui James Berkenbile pentru corectarea sa tehnică a manuscrisului final, înainte de a trece la tipar înainte de a vă scufunda în scripting-ul PowerShell și crearea de instrumente, trebuie să știți exact ce implică acestea - și aveți nevoie doar de un curs intensiv în limbajul de scripting PowerShell Asta vom realiza în această parte a cărții Dacă materialul din această parte pare la nivel înalt și scurt, este în regulă Aceasta este intenția noastră: în acest moment, toate aceste subiecte de bază sunt puțin conceptuale și abstracte, așa că vom încerca să le scoatem din drum rapid Rămâi cu ea, pentru că le vom revedea pe toate mai târziu, când vom putea face acest lucru într-un context mai real și mai semnificativ Dacă sunteți în căutarea unei acoperiri mai complete, luați o parte din Learn PowerShell într-o lună de prânz, ediția a -a Sau, dacă ai chef să mergi all in, alege PowerShell în profunzime, tot de la Manning Press Windows PowerShell este un produs interesant Este unul dintre puținele produse Microsoft care au fost concepute în mod explicit pentru mai multe publicuri diferite În cadrul acestor segmente de public vor fi începători, utilizatori intermediari și experți, dar în multe cazuri există puține intersecții între categoriile de public Oamenii care folosesc shell-ul ca interfață de linie de comandă – utilizatorii de instrumente, în terminologia noastră – nu sunt întotdeauna interesați să abordeze shell-ul în alt mod Oamenii care folosesc shell-ul pentru a crea instrumente – creatorii de instrumente, așa cum le-am spune noi – ar putea folosi shell-ul ca instrument de dezvoltare de cele mai multe ori și doar rar folosesc PowerShell ca interfață interactivă de linie de comandă Această carte se adresează oamenilor – în primul rând administratorilor – care încep în acea secundă, publicul care produce instrumente Am împrumutat termenul de fabricare a sculelor din industria sculelor și matrițelor, deoarece considerăm că este potrivit pentru PowerShell În această industrie, există mașiniști care produc o varietate de piese și produse diferite Pentru a face acest lucru, ei folosesc unelte - burghie, matrițe și așa mai departe - care sunt fabricate de producătorii de scule și matrițe Ambele audiențe – mașiniștii și producătorii de scule și matrițe – utilizează multe dintre aceleași abilități și echipamente, dar fac acest lucru din motive diferite Producătorii de scule știu că uneltele pe care le fac nu sunt un produs final, ci sunt mai mult un mijloc pentru un scop Ei știu că produsul lor de muncă va fi consumat de un alt expert, deși un expert cu un set ușor diferit de obiective și un inventar diferit de abilități În lumea PowerShell, cea mai largă audiență de utilizatori shell folosește doar instrumentele oferite acestora Ei rulează comenzi și, cel mult, combină o buneii de comenzi diose într-un script pentru a automatiza un proces complex, în mai mulți pași Producătorii de scule , pe de altă parte, sunt concentrați mai puțin pe realizarea unei sarcini de producție și mai mult despre crearea unui instrument reutilizabil, ambalat, care să poată îndeplini acea sarcină - și să facă acest lucru într-un mod care să permită instrumentului să fie transmis utilizatorilor instrumentului, care pot consuma instrumentul în propriile lor scripturi mai simple Sigur, există crossover Astăzi, Bob s-ar putea concentra pe obținerea unor noi utilizatori furnizați în Active Directory După ce a făcut asta manual pentru un timp, Bob s-ar putea gândi: „Știi, pun pariu că aș putea pune totul într-un script pe care cineva de la Resurse Umane l-ar putea rula și să-mi scot totul din farfurie ” Bob tocmai s-a pregătit să devină un producător de instrumente: folosind PowerShell nu pentru a îndeplini o sarcină în mod direct, ci permițând altcuiva - adesea cineva mai puțin competent din punct de vedere tehnic - să îndeplinească singur sarcina Folosim termenul de creare de instrumente în loc de scripting pentru a evidenția ceea ce credem că este o diferență cheie între cele două Pentru noi, un scenariu este ceva ce faci pentru tine S-ar putea să fie puțin urât, dar tu ești singurul care va ști Puteți face o mulțime de presupuneri cu privire la modul în care va fi rulat, pentru că veți fi cel care îl va conduce Scripturile sunt adesea rapide și murdare și, deși ar putea fi lungi și complicate, sunt doar o modalitate de a automatiza ceva pe care numai tu îl vei face vreodată Pentru un instrument, pe de altă parte, puteți face mai puține presupuneri Îl vei preda altcuiva și nu vei fi prin preajmă să-l îngrijești Instrumentul dvs trebuie să fie mai structurat și mai rezistent la erori Trebuie să verificați intrarea pe care o oferă instrumentul dvs pentru a vă asigura că este corect și utilizabil Instrumentul dvs trebuie să fie puțin mai profesionist și puțin mai robust decât ceva pe care l-ați conduce singur Crearea de instrumente este un pas sub dezvoltarea completă a software-ului Producătorii de instrumente încă operează în întregime în PowerShell, radier dian trecând, de exemplu, în Visual Studio și într-un limbaj NET Framework precum G# Producătorii de instrumente trebuie încă să dea dovadă de disciplină și maturitate a unui dezvoltator – anticiparea și gestionarea erorilor, validarea intrărilor utilizatorilor și așa mai departe – dar producătorii de instrumente lucrează într-un mediu mai simplu pentru dezvoltatori și adesea produc instrumente mai puțin complexe Dezvoltatorii accesează adesea porțiuni largi ale NET Framework; Producătorii de instrumente PowerShell se bazează mai mult pe comenzile PowerShell și este posibil să nu acceseze direct Framework-ul sau pot face acest lucru doar minim Admitem că este o linie fină; în cele din urmă, devine mai mult despre persoană Dacă Visual Stu dio pur și simplu nu este ceașca ta de ceai și ai mai rămâne într-un mediu mai simplu, asemănător scripturilor, ești un producător de instrumente Bun venit la bord Cel puțin, ar trebui să fiți un administrator Microsoft încrezător și priceput Indiferent dacă lucrați cu Windows, Exchange Server, SharePoint Server sau chiar cu produse terțe precum VMware vSphere, ar trebui să știți cum să îndepliniți rapid orice sarcini de care aveți nevoie cu tehnologia aleasă Vom păstra exemplele din această carte destul de generice, astfel încât să vă puteți concentra pe abilitățile și tehnicile radier tiian asupra tehnologiei gestionate; De asemenea, vom păstra exemplele foarte dimensionate în șablon, astfel încât să le puteți despărți mai ușor și să le reutilizați pentru propriile utilizări, în propriul mediu Rețineți, scopul aici este să vă învețe cum să creați instrumente în PowerShell, nu să vă învețe cum să realizați sarcini în Exchange sau SharePoint sau orice altceva Abilitățile pe care le predăm sunt universale și pot fi aplicate oricărei tehnologii care este administrată prin PowerShell De asemenea, ar trebui să aveți o experiență solidă ca utilizator de instrumente în Windows PowerShell Ar trebui să fii încrezător în tastarea și rularea comenzilor, a face față erorilor din linia de comandă și chiar a înșira comenzile într-un script simplu Dacă nu, vă sugerăm să începeți cu Aflați „Windows PowerShell v într-o lună de prânz ( ), care este o modalitate mai bună de a învăța acele abilități fundamentale În mod ideal, ar trebui să aveți chiar și puțină programare sau scripting în spate Orice limbaj este fme—C++, C#, Perl, PHP, VBScript, Python, orice Doar suficient pentru a vă permite să recunoașteți o declarație if, să înțelegeți ce face o buclă și așa mai departe Nu veți avea nevoie de abilități majore de programare în această carte și, dacă nu aveți nicio experiență de programare, vă veți înțelege în continuare pur și simplu; a avea acel fundal va face lucrurile un pic mai lin pentru tine Înainte de a începe, există câteva lucruri de care ai nevoie În primul rând, asigură-te că ai citit „Această carte este pentru tine?” deoarece acea secțiune descrie abilitățile și experiența pe care ne așteptăm să le aduceți la masă În plus, ne așteptăm să aveți acces la un computer Windows care are instalat Power Shell v Dacă aveți PowerShell, dar nu sunteți sigur dacă este v , deschideți-l, tastați $PSVersionTable și apăsați Enter Versiunea PowerShell ar trebui să fie Dacă nu este, vizitați http://download microsoft com , introduceți „PowerShell” în câmpul de căutare și descărcați v din Windows Management Framework, pachetul care include Power Shell potrivit pentru sistemul dvs de operare Vă recomandăm insistent ca computerul dvs Windows să ruleze fie Windows , fie Windows Server și vă recomandăm și mai insistent să îl rulați într-o mașină virtuală de vreun fel În acest fel, dacă dai peste cap ceva, ai stricat doar o mașină virtuală și nu computerul tău real Trebuie să vă asigurați că execuția scriptului este activată pentru PowerShell rulând Set-ExecutionPolicy și specificând fie Unrestricted, fie RemoteSigned, în funcție de setarea preferată a organizației dvs Dacă procedați astfel și primiți un avertisment că politica de execuție este setată prin Politica de grup, asigurați-vă că politica de execuție este fie Unrestricted, fie RemoteSigned Dacă nu este unul dintre acestea, contactați administratorul Active Directory pentru a discuta situația Pentru această carte, presupunem că puteți rula Scripturi fără a fi nevoie să le semnați digital Din nou, lucrul într-o mașină virtuală în afara domeniului este o modalitate bună de a rezolva această problemă Pentru o mare parte a acestei cărți, presupunem că veți avea privilegii de administrator local pe mașina dvs sau în mașina virtuală de testare Când rulați PowerShell, bara de titlu a ferestrei ar trebui să spună „Administrator”; dacă nu, închideți shell-ul, faceți clic dreapta pe pictogramă și selectați Run As Administrator Dacă acesta nu este disponibil sau nu funcționează, atunci va trebui să rezolvi problema înainte de a continua Multe dintre instrumentele pe care le veți construi în această carte sunt concepute pentru a interoga mai multe computere Dacă aveți un singur computer cu care să lucrați, puteți oricând să specificați „localhost” de mai multe ori, pentru a simula conectarea la mai multe mașini Dar dacă este posibil să aveți două sau trei mașini cu care să lucrați, este o experiență mai interesantă Am folosit un serviciu de laborator virtual bazat pe web numit CloudShare com pentru a ne configura mediul pentru această carte Am creat un controler de domeniu într-un domeniu numit AD R și apoi am adăugat un computer client și un server membru la acel domeniu Asta ne-a dat trei computere cu care să ne jucăm Figura arată mediul nostru de testare, pe care îl vom folosi pe parcursul acestei cărți CloudShare com este un serviciu comercial și are o taxă lunară sau anuală Nu este singurul serviciu de acest gen (s-ar putea să știți despre altele care sunt gratuite sau care costă închiriere) și este posibil să aveți resurse la locul de muncă pentru a aduce câteva mașini virtuale pe care să le utilizați ca laborator Indiferent ce ați alege să faceți, credem că este vorba – chiar și o taxă zilnică pentru un serviciu precum CloudShare com – așa că puteți utiliza PowerShell într-un mediu mai realist Crearea de instrumente este un set de sarcini de mare ligă, iar asta înseamnă că va trebui să fii dispus să investești puțin pentru a avea cea mai bună experiență de învățare Puteți face întreaga carte pe o singură mașină, dar nu credem că vă pregătim pe deplin pentru lumea reală Ne place CloudShare com în principal pentru că ne permite să pornim mașini virtuale, complet configurate (chiar și ca controler de domeniu) în câteva secunde, așa că este foarte convenabil pentru noi Test environment diagram Test environment diagram Scopul nostru din cartea diis nu este să vă învățăm cum să configurați un controler de domeniu sau un mediu de testare; ne așteptăm să aveți deja abilități diose Considerăm că drese sunt abilități de bază pe care ar trebui să le aibă fiecare administrator de rețea Microsoft Dacă nu le aveți, este foarte probabil că nu este cartea potrivită pentru dvs Pentru unele dintre exemplele noastre cu mai multe computere, presupunem că Windows Management Instrumentation (WMI) poate comunica între aceste mașini, ceea ce necesită de obicei ca acestea să nu aibă un firewall local care să blocheze niciun port Poate doriți chiar să dezactivați paravanul de protecție Windows sau alt software de paravan de protecție local pe mașina dvs de testare Bineînțeles, nu ați face asta într-un mediu de producție, dar făcând acest lucru într-un mediu de laborator (sau într-o mașină virtuală de testare) vă va permite să urmați fără a fi nevoie să vă faceți griji cu privire la configurațiile complexe Pentru alte exemple, folosim PowerShell Remoting Puteți activa Remoting rulând Enable-PSRemoting pe fiecare dintre mașinile dvs de testare (asigurați-vă că rulați aceasta ca Administrator) Presupunem că orice mediu multi-mașină pe care îl configurați va avea toate mașinile într-un singur domeniu, astfel încât Remoting va funcționa în cea mai simplă configurație implicită Dacă aveți doar o singură mașină, rularea comenzii pe ea și întotdeauna folosind localhost ca nume de computer la distanță (chiar dacă utilizați localhost de mai multe ori) va funcționa, de asemenea, chiar dacă singura mașină nu se află deloc într-un domeniu Asigurați-vă că Enable-PSRemoting se finalizează fără eroare Dacă trebuie să aflați mai multe despre Remoting, luați în considerare ghidul gratuit Secrets of PowerShell Remoting disponibil la Pentru porțiuni din această carte, veți avea nevoie și de SQL Server Vă recomandăm să descărcați SQL Server Express (oricare ar fi cea mai recentă versiune) și să descărcați în mod specific pachetul care include Express Management Tools (uneori, va trebui să descărcați SQL Server Express și să descărcați independent instrumentele de management Express corespunzătoare pentru asta versiune—Microsoft se răzgândește frecvent cu privire la modul în care le împachetează) În acest fel, veți obține atât backend-ul SQL Server, cât și instrumentele de management bazate pe GUI Instalați aceste pachete în computerul dvs de testare sau în mașina virtuală folosind opțiunile de instalare implicite SQL Server Express este gratuit și îl veți găsi la — trebuie doar să introduceți „sql express” în câmpul de căutare Rețineți că PowerShell v necesită Microsoft NET Framework v ; SQL Server, în funcție de versiunea pe care o descărcați, va necesita, de asemenea, una sau mai multe versiuni specifice de Framework Citiți cerințele preliminare de pe pagina de descărcare și asigurați-vă că aveți tot ce este necesar Dacă alegeți să lucrați pe un sistem de operare Windows Server, instalați Windows Power-Shell ISE Pentru a face acest lucru, din consola PowerShell, rulați Add-WindowsFeature powershell-ise și așteptați câteva minute Nu ar trebui să fie necesară repornirea pentru asta Există alte câteva lucruri pe care poți alege să le ai la îndemână dacă vrei Ele nu sunt absolut necesare, dar dacă alegeți să continuați anumite subiecte în această carte, veți dori niște instrumente pentru a ușura viața Acestea includ următoarele: PowerShell Studio, cunoscut anterior ca PrimalForms — Acesta va fi util în capitolele și Acesta este un produs comercial, disponibil prin Este disponibilă o încercare gratuită Un editor XML — Acesta va fi util de câteva ori pe parcursul acestei cărți Avem tendința de a codifica manual XML într-un editor de text cum ar fi Notepad, dar dacă ești serios cu el, un editor dedicat poate fi util Microsoft InfoPath — Dacă începeți să creați fișiere de ajutor în mai multe limbi pentru instrumentele pe care le creați, atunci InfoPath poate fi o modalitate ușoară de a produce fișierele sursă necesare Avem tendința de a rămâne cu ajutorul într-o singură limbă, bazat pe comentarii, care nu necesită XML sau InfoPath, dar este posibil să vă simțiți diferit când ajungeți la capitolul Această carte este concepută pentru a fi citită câte un capitol, în ordine Fiecare capitol se bazează pe cele dinaintea lui, așa că nu recomandăm sări peste tot, mai ales la prima citire Fiecare capitol este dimensionat astfel încât să poată fi citit în aproximativ o oră și, în majoritatea cazurilor, aceasta ar trebui să includă suficient timp pentru a finaliza laboratorul practic de la sfârșitul fiecărui capitol Nu putem sublinia suficient beneficiile laboratoarelor practice Asigurați-vă că le faceți Ele ajută cu adevărat la consolidarea conceptelor Dacă rămâi blocat pe unul, urcă-te și cere ajutor De asemenea, puteți vizita faceți clic pe imaginea de copertă a acestei cărți și descărcați exemple de răspunsuri de laborator Dar nu реек până nu ai dat cel puțin o șansă laboratorului pe cont propriu! Site-ul web vă va direcționa, de asemenea, către resurse suplimentare suplimentare, inclusiv capitole bonus, instrumente, videoclipuri demonstrative narate și multe altele În cele din urmă, rămâneți cu programul de un capitol pe zi Poate fi tentant să măriți cartea, dar aveți încredere în noi: citind un capitol pe zi, îi acordați timp creierului să proceseze în fundal învățarea zilei Dacă vă simțiți gata să mergeți mai departe a doua zi, mai faceți un capitol Dacă nu, recitiți capitolul din ziua precedentă și lăsați-vă creierul să-l proceseze puțin Hop Online ( ) și pune întrebări clarificați orice probleme sau puncte de blocare Mai presus de toate, nu trece la capitolul următor până nu ești sigur că l-ai primit complet pe cel anterior Scopul aici este ca tu să ai succes și să înveți ceva, nu doar să alergi până la sfârșitul cărții! Luna dvs de prânz începe chiar cu următorul capitol Mult noroc! Când începeți să utilizați limbajul de scripting PowerShell, este ușor să întâlniți o serie de probleme și obstacole pe care de obicei nu le-ați vedea când executați comenzi În acest capitol, vom încerca să eliminăm aceste obstacole din față, astfel încât să puteți începe să creați instrumente cu mai puține bătăi de cap Din perspectiva noastră, PowerShell este în primul rând o interfață de linie de comandă (CLI) Asta înseamnă că executați comenzi și obțineți rezultate imediate La fel ca multe CLI bune, PowerShell conține un limbaj de scripting, dar utilizarea limbajului diat este opțională Pentru a face instrumente, vom folosi cu siguranță limbajul! Vestea bună este că, în comparație cu limbaje precum VBScript, Perl, PHP și altele, limbajul PowerShell este incredibil de simplificat, constând din aproximativ o duzină de cuvinte cheie Cel mai simplu, scriptarea ar putea implica doar rularea mai multor comenzi specifice într-o anumită secvență Scripturile mai complexe ar putea începe să aplice logica - executați această comandă numai dacă această condiție există Scripturile ar putea fi nevoite să execute o anumită sarcină pe mai multe ținte diferite - verificarea unui număr de fișiere diferite, reconfigurarea unui număr de servicii diferite și așa mai departe Ideea este automatizarea, în cele mai multe cazuri, de obicei parcurgerea unor serii de pași pe care i-ați putea face manual, dar pe care i-ați codifica într-un instrument care poate fi reutilizat și repetat mai ușor, poate de către alți oameni PowerShell merge la anumite limite, în mod implicit, pentru a împiedica executarea scripturilor Asta se întâmplă în principal pentru că în trecut (gândiți-vă la epoca VBScript, aici) scripturile erau folosite cu răutate O discuție detaliată despre securitatea PowerShell este în afara domeniului acestei cărți; ar trebui să fiți deja familiarizați cu politica de execuție, ce face aceasta și ce setare este adecvată pentru organizația dvs Dacă nu, consultați ajutorul pentru comanda Set-ExecutionPolicy de la PowerShell, inclusiv fișierele de ajutor „Vezi și” la care face referire De asemenea, puteți consulta „Alerta de securitate!” capitolul Aflați „Windows PowerShell v într-o lună de prânz, care include o discuție mai detaliată despre conceptele și mecanismele de securitate ale PowerShell Pentru moment, trebuie să decideți care politică de execuție este potrivită pentru dvs în ceea ce privește laboratoarele practice ale acestei cărți În mod ideal, veți lucra într-o mașină virtuală de sine stătătoare, izolată, oferindu-vă posibilitatea de a vă seta politica de execuție la RemoteSigned sau Unrestricted, fără consecințe potențial negative De asemenea, ar trebui să știți care este politica de execuție a mediului de producție și să vă gândiți la modul în care aceasta va afecta instrumentele bazate pe scripturi pe care le veți crea și utiliza în acel mediu Dacă scrieți Scripturi, atunci este de la sine înțeles că veți dori să le executați Aici o altă caracteristică de securitate PowerShell poate crea o problemă După cum se arată în figura , nu puteți introduce pur și simplu numele unui fișier script pentru a-l rula Chiar și cu politica de execuție configurată pentru a permite Scripturi, trebuie să precedați numele fișierului scriptului cu o cale În figura , veți vedea \path în uz, care se referă la directorul curent De asemenea, puteți furniza orice altă cale absolută sau relativă pentru a rula un script, dar trebuie să furnizați o cale de orice fel Dacă lucrați în PowerShell ISE – și ne așteptăm că veți petrece cea mai mare parte a acestei cărți făcând acest lucru – atunci puteți face clic pe pictograma verde Play pentru a rula orice script este Adm'rfstra o Wr'dows PowerShe ІЖ ВШ Terniul „a face ceva* nu este recunoscut ca program Verificați к ortografia numelui, sau dacă este din nou | numele unui cmdlet, funcție, calea scriptului a fost inclus, verificați dacă „| La linia:l char :lj + do-somethingB + Categorynfo : ObjectNotFound: (d o-some thing:String) CommandNotF] + FullyQualifiedErrorld: CommandNotFoundExc epțiuneaB eu PS C:',> ,\> -Something psl Rularea unui script necesită să furnizați o cale către acesta — Windows PoweiSiiell ISF ' = [ ts) [ S fișier Edil View T oo$ Oebug Add-ons Help d v a \ a p E ■ î- [в] п п Q г B | Untifledl ps! | Cc-Some hing psl X O Writc—Gazda „Did СлмаГhi ПП ' PS C;\Windows\ ystem > C Abo-Somethinp psl Pid SometMne ps c:\vdndows\sy st entâ > deschideți în fila curentă Figura arată cum arată și cum puteți configura ISE pentru a afișa atât scriptul, cât și rezultatul său în panouri diferite Rețineți că un mod în care nu puteți rula Scripturi, cel puțin în mod implicit, este să faceți dublu clic pe diem în Windows Explorer Tipul de fișier PS , care este utilizat pentru scripturile PowerShell, nu este configurat ca tip de fișier executabil Din nou, aceasta este o măsură de securitate, astfel încât dublu clic pe un script îl deschide în Notepad radier dian rulând-l Nu vă recomandăm să schimbați această setare Scripturile, veți observa, continuă să folosească o extensie de nume de fișier PS , chiar dacă rulează sub PowerShell v desemnează versiunea tie a limbajului de scripting PowerShell, care nu s-a schimbat cu adevărat de la PowerShell vl Orice ați face, vă rugăm să nu utilizați Notepad pentru a edita scripturi PowerShell Notepad-ul poate fi gratuit, dar nu face nimic pentru a ușura procesul Ceea ce este mult mai bun, și la fel de gratuit, este PowerShell ISE, care a fost prezentat în figura Versiunea a tiie ISE (care vine cu PowerShell v ) este robustă, oferă numeroase funcții utile, cum ar fi completarea codului IntelliSense și codurile colorate comenzile pentru a vă ajuta să vă asigurați că le introduceți corect De exemplu, așa cum se arată în figura , ISE utilizează meniurile pop-up IntelliSense pentru a vă ajuta să completați mai rapid numele comenzilor și pentru a preveni greșelile de scriere Edil Vie* Edil Vie* ibug Add-ors Hep ibug Add-ors Hep Windows PoweiSheli IS ; Fișier Edil Vie* 'cos Oebog Add-ors Hep м Чіа И | | Г ■ | Li | В CT [g | Q П B JnLiiJedl psl | Dc-Sore hhg ps' * X Wrrte-Host [[-Object] ] [-NoNewline] [-Separator l [-ForegroundColor ] [-BackgroundCoior ] [ ] Utilizarea IntelliSense pentru a completa numele comenzilor Vă încurajăm cu tărie să vă obișnuiți cu această funcție, apăsând Enter sau Tab pentru a selecta un element din meniu, decât tastând manual numele întregii comenzi Ceea ce nu tastezi, nu poți greși! Acum este un moment bun pentru a vă scufunda în ISE și a începe să încercați această caracteristică Este nou în versiunea , așa că dacă nu vedeți meniurile IntelliSense, trebuie să instalați PowerShell v Figura prezintă o altă caracteristică ISE: finalizarea parametrilor Doar introduceți un nume de comandă, un spațiu și o liniuță, iar ISE vă solicită cu toți parametrii disponibili ai acelei comenzi Din nou, nu puteți scrie greșit ceea ce nu introduceți, așa că alegerea unui parametru din listă vă va asigura că este tastat corect și complet și că este un parametru legitim pentru acea comandă Figura arată cum ISE vă poate ajuta și să preveniți erorile Observați sublinierea roșie ondulată (am adăugat o săgeată pentru a o indica)? Asta vă spune că există o problemă de sintaxă În acest caz, pentru că am tastat o virgulă, dar nu am scris nimic după ea Aceasta este o caracteristică grozavă care vă ajută să evitați mesajele de eroare mai târziu: asigurați-vă doar că ați înlăturat toate squiggles roșii și sunteți cu un pas mai aproape de un script fără erori! Windows PowerShell IS i ' = i Э | % (f ■ bjț Bor g JnliJed! psl | Dc-Sonte M'ig psl" X O - CI KT * [System Slring} CUîs | Recurs OirectRead Autentificare local Acreditare CcmputerName Spațiu de nume — ErrorAction * Folosind numele parametrului IntelliSense în ISE Windows PowerShell ISE ' = ■ ® © fișier Edil View T cos Oebug Add-ons Hep □ ' “ -i □ X Г ■ î в n gj □ r B | Uhliliedi ps | Cc-Unele hing psV X o „T?;- IM Roșu subliniază în mod ondulat caii să vă atenționați la erorile de sintaxă Ar trebui să acordați o atenție deosebită codării culorilor ISE, deoarece este un alt mod în care ISE vă poate indica erori potențiale De exemplu, figura arată o comandă pe care am tastat-o incorect, forțând codificarea culorilor ISE-ului să fie incorectă și afișând un squiggle roșu Obișnuindu-vă cu ceea ce ar trebui să fie culorile , veți deveni mai atent la erori atunci când culorile arată greșit | Unliiiedbpsl | Cc-Ceva ps'i* X o э Lc ); ■ ®{ { / }} Windows PowerShell ISE ' = è fișier Edil View Toos Oebug Add-ons Hep v □ x ■ ■c в mg] а г Codarea culorilor este un alt mod în care ISE vă alertează cu privire la posibile erori de sintaxă Erorile de codificare a culorilor pot proveni și din elemente împerecheate necorespunzător, cum ar fi paranteze, ghilimele și așa mai departe Căutați doar locul în care culoarea merge prost - deseori va fi însoțită de o mârâială roșie - și acesta este aproape de locul în care va trebui să vă puneți soluția După cum se arată în figura , ISE merge mai departe prin evidențierea elementelor pereche care se potrivesc Pentru acest exemplu, am plasat cursorul chiar lângă o paranteză de închidere, iar subdiviziunea ISE l-a evidențiat și paranteza de deschidere a asocierii Acest lucru ne-a ajutat să ne asigurăm că totul a fost imbricat corespunzător, închis și fără erori — Windows PoweiShell ISF = й fișier Edil Vizualizare „co$ Oebvg Add-ons Hep d " * si X Г ■ ti в a ! Q г и | Ufililiedl psl | Cc- o Get-Cimlnstance -ClassName Win OperatingSystem -ComputerName DONJ ONES D SystemDirect Organization BuildNumber RegisteredU SerialNumbe Versiune ser r C:\Window Don Jones - Este o idee bună să încercați această comandă pe cont propriu Vom construi pe diis pe tot parcursul diis și în capitolele următoare, așa că asigurați-vă că comanda die rulează în această formă mai simplă vă va ajuta să vă asigurați că nu întâmpinați probleme mai târziu Am ales să folosim Get-Cimlnstance, care este nou în PowerShell v Necesită ca Windows Remote Management, sau WinRM, să fie activat pe computerul de la distanță (rulați Enable-PSRemoting pe computerul de la distanță pentru a activa WinRM și a configura o configurație implicită de la distanță) și necesită să rulați PowerShell ca utilizator care este, de asemenea, un Administrator local pe mașina de la distanță Dacă aveți doar o singură mașină cu care să testați, furnizați doar numele computerului în loc de numele unui computer de la distanță Pentru următorul pas, ne vom întoarce la PowerShell ISE Vom copia comanda noastră în clipboard (dacă ați început în consola PowerShell, evidențiați comanda și apăsați Enter pentru a o crea) și apoi lipim comanda în ISE După cum puteți vedea în figura , operațiunea noastră de copiere și inserare a inclus o parte din promptul PowerShell, precum și o întoarcere inutilă Va trebui să le edităm înainte de a rula comanda din nou Figura prezintă scriptul editat, care include comanda completă pe o singură linie Vom rula acest lucru făcând clic pe pictograma verde Play din bara de instrumente (puteți apăsa și F ) Acesta este un pas important, deoarece asigură că comanda noastră, care a funcționat bine în consolă, a fost copiată corect în ISE După cum se arată în figura , putem confirma că ISE afișează aceeași ieșire, confirmând astfel că am lipit și am editat corect comanda die Încă o dată, asigurați-vă că puteți urma și executați această comandă în ISE Numele computerului pe care l-am folosit va trebui să fie înlocuit, mai ales numele computerului dvs , numele unui computer la distanță din rețeaua dvs sau chiar localhost În acest moment, puteți salva fișierul matriță Figura arată cum salvăm acest lucru ca C:\Get-OSInfo psl Am ales rădăcina die C:\drive din două motive: În primul rând, face scriptul nostru ușor de accesat și intenționăm să-l rulăm mult pe parcursul capitolului diis, astfel încât să creeze o cale mai scurtă de tastare În al doilea rând, salvarea în locație ne asigură că am rulat die shell ca Administrator (puteți vedea, de asemenea, că bara de maree a ferestrei pentru ISE spune „Administrator”, care confirmă și permisiunile noastre) Puteți alege să salvați diis într-un padi alternativ cu un nume scurt, cum ar fi C:\Scripts sau ceva similar Am ales un nume de fișier script care arată ca un nume de cmdlet PowerShell: folosește un verb, urmat de un substantiv singular Dacă este posibil, încercați să respectați verbe standard și aprobate Dacă nu știți ce sunt diey, rulați Get -Verb Extensia de nume de fișier psl informează Windows că diis este un fișier script PowerShell După ce ați salvat scriptul die, vrem să-l testăm din nou rulând-l de pe consolă (puteți folosi consola die în die ISE sau ry ry mtdon mtdon Cor pl e ied Cor pl e ied| Ln Col | Q % Salvarea scriptului ca C:\Get-OSInfo ps! reveniți la fereastra normală a consolei), așa cum se arată în figura Efectuarea unui test rapid după fiecare modificare ne ajută să ne asigurăm că am făcut totul corect The Ad-'in s! r ao r Cel mai rău lucru pe care îl puteți face în Windows PowerShel ISE este să faceți o grămadă de modificări și apoi să le testați pe toate odată, deoarece, dacă ceva s-a stricat, este mai dificil să vă dați seama care dintre multele dumneavoastră modificări a cauzat problema File Edil /iffw Toos Debug Add*ors H«p File Edil /iffw Toos Debug Add*ors H«p в ra § QjrB в ra § QjrB Încă o dată, asigură-te că poți urmări până în acest punct Observați că a trebuit să introducem o cale (\ care înseamnă „dosarul curent”) în fața numelui scriptului nostru pentru a-l face să ruleze și că am folosit deja Set-ExecutionPolicy pentru a activa execuția scriptului pe computerul nostru Să luăm în considerare ce am făcut până acum, din perspectiva unui producător de scule Am creat acest script, care poate interoga Informații de la un computer la distanță Vrem să dăm asta altcuiva pentru a-l folosi Dar probabil că vor dori să interogheze alt computer, precum și pe cel cu care am testat Le-am putea spune doar: „Uite, oricând vrei să folosești asta, deschide-l în Notepad sau ISE Trebuie să schimbați numele computerului, dar asigurați-vă că nu schimbați nimic altceva, altfel îl puteți rupe ” Ce ar putea merge prost? Ar fi mult mai logic să nu avem alți oameni să editeze scenariul nostru în mod obișnuit – cu cât editează mai puțin, cu atât se vor rupe mai puțin În plus, atunci când cineva rulează o comandă PowerShell obișnuită, nu trebuie să editeze nimic - doar furnizează informații unui parametru Asta ar trebui să facem și noi: să furnizăm un parametru pentru a accepta orice Informație modificabilă Privind scriptul nostru, probabil că există o singură informație pe care am schimba: numele computerului Deci vom parametriza asta Înainte de a face acest lucru, trebuie să alegem un nume de parametru Scopul aici ar trebui să fie să rămână consecvent cu restul acțiunilor PowerShell Deci, când vedeți o comandă Power Shell care acceptă un nume de computer, ce parametru folosește pentru a face acest lucru? Veți constata că „a rămâne consecvent cu restul PowerShell” este o temă majoră în această carte Pe măsură ce construim instrumente, dorim ca acestea să arate și să funcționeze cât mai mult ca comenzile PowerShell „reale” posibil Vă vom cere în mod continuu să vă uitați la restul shell-ului pentru inspirație și să rămâneți cât mai aproape de ceea ce face deja PowerShell Privind comenzi precum Get-Service, Get-Process, Invoke-Command și chiar Get-Cimlnstance, vedem că PowerShell folosește întotdeauna un parametru -computerName pentru comenzile care pot accepta un nume de computer Deci vom folosi același nume de parametru în scriptul nostru Lista arată scriptul nostru revizuit, cu modificările cu caractere aldine Ca o scurtă reamintire, puteți descărca toate înregistrările numerotate din această carte, vizitând Faceți clic pe coperta acestei cărți pagina principală și apoi căutați în secțiunea Descărcări Param( [șir]ȘcomputerName = 'localhost' ) Get-Cimlnstance -ClassName Win OperatingSystem -ComputerName ȘcomputerName Există mai multe lucruri pe care trebuie să le subliniem - și vă rugăm să le citiți cu atenție: Am definit parametrul într-un bloc Param () care folosește parametrii pentru a include parametrii noștri În parentii, am indentat fiecare zi folosind tasta Tab PowerShell nu necesită indentarea matriței, dar este foarte important ca scriptul matriței să fie lizibil și mai ușor de depanat Întotdeauna binevenim întrebările dvs la Dar dacă nu vă puteți face timp pentru a vă forma Scripturile frumos, răspunsul nostru va fi „Remediați mai întâi formatarea” Nu vă putem ajuta să remediați problemele unui script greu de citit, așa că vă rog, vă rog, acordați atenție formatării De asemenea, vă ușurează depanarea Am definit un tip de date, [șir], pentru parametrul nostru Parametrul este practic o variabilă, așa că primește un semn dolar ($) în fața numelui său Am atribuit o valoare implicită, localhost, care va fi folosită dacă cineva rulează scriptul și nu furnizează o valoare pentru parametru Am înlocuit numele computerului nostru codificat cu o nouă variabilă $computerName Acesta este ceea ce folosește parametrul Doar pentru că am trecut parametrul tiie unui parametru -ComputerName nu ne-a forțat să folosim $computerName ca nume de parametru Am fi putut folosi cu ușurință $f red sau $x sau $orice Am folosit $computerName pentru consecvență: comenzile Power Shell folosesc -ComputerName ca nume de parametru ori de câte ori este acceptat un nume de computer și am vrut să rămânem consecvenți cu această practică După Win OperatingSystem, veți observa un caracter de backtick (') Nu este o bucată de toner rătăcită pe pagină – este important! Vedeți, nu aveam suficient spațiu în această carte pentru a pune întreaga comandă pe o singură linie Tacul înapoi scapă din următorul retur, permițându-ne să continuăm comanda pe următoarea linie Ceea ce este esențial, dacă tastați țiiis în dvs , este ca tastatura înapoi să fie urmată imediat de o întoarcere la cărucior, nu de spații sau file sau orice altceva Dacă întoarcerea carușului nu este imediat după tiie backtick, tiie trick nu va funcționa și scriptul tiie nu va rula Desigur, în versiunea dvs nu sunteți limitat de spațiu, așa că nu ezitați să faceți din tiiis o comandă cu o singură linie Cu toate acestea în afara drumului, încercați să rulați scriptul Vedeți figura , unde puteți vedea că PowerShell deschide fișierul script și citește blocul Param (), astfel încât să poată oferi indicii IntelliSense pentru parametrul -ComputerName Rece! Acesta începe să funcționeze la fel ca un cmdlet PowerShell adevărat! — Ad'cinisVaîo': W 'dows Power Shel ]$F = s? fișier £drt Vizualizați Tc-ds Oebug Addors Hep a \tOOls ps! Acesta a rulat scriptul, care a definit funcția, dar ia spus lui PowerShell să omite procesul de curățare Post Script (este o simplificare, iar în capitolul următor vom explica mai detaliat ce sa întâmplat de fapt) Rezultatul este ca scriptul să fie executat, dar funcția Get-OSInfo a rămas definită Prin urmare, am putut să-l executăm și dorim să subliniem că am făcut-o fără a oferi o cale Get-OSInfo nu este un script acum, așa că nu furnizați o cale către acesta Este o comandă (în special, o funcție) care se află în memoria PowerShell Puteți rula funcția Dir: pentru a vedea funcția aflată în funcția „drive” din PowerShell Asigurați-vă că puteți urmări și că puteți rula funcția Dir: pentru a vedea funcția în memorie Dotsourcing este o tehnică utilă Există totuși dezavantaje: unul este că deseori vei face modificări la scenariul tău și vei dori să testezi Witii dot sourcing, tu trebuie să re-punctați sursa fișierului script de fiecare dată când doriți să testați cele mai recente modificări Acest lucru poate fi oarecum enervant și este cel mai mare dezavantaj al aprovizionării cu puncte De asemenea, dacă decideți că doriți să eliminați funcțiile scriptului din memoria PowerShell, nu există nicio modalitate foarte simplă de a face acest lucru; trebuie să ștergeți manual pe fiecare de pe unitate, ceea ce din nou este cam enervant Credem că este mai ușor – doar în scopuri de testare, înțelegi – ca scriptul să definească funcția și, de asemenea, să ruleze funcția În acest fel, PowerShell poate curăța în continuare după ce scriptul se termină, eliminând funcția din memorie, dar vom vedea că funcția funcționează Următoarea listă arată scriptul Tools psl revizuit, care adaugă o linie la sfârșit funcția Get-OSInfo { param( [șir]ȘcomputerName = 'localhost' ) Get-Cimlnstance -ClassName Win OperatingSystem -ComputerName ȘcomputerName } Get-OSInfo -computemame SERVER Ar trebui să modificați Tools psl pentru a arăta astfel, deși veți dori să furnizați un nume de computer valid (sau localhost), astfel încât scriptul dvs să funcționeze cu adevărat Rulați-l pentru a vă asigura! Figura arată că acest lucru este puțin mai ușor de testat - doar rulați scriptul în mod normal Acum este mai ușor să modificați, să testați, să modificați, să testați și să repetați Acum putem doar să facem clic pe butonul Redare din bara de instrumente a ISE sau să apăsăm F în timp ce ne uităm la script, pentru a-l testa rapid Dacă doriți ca scriptul să ruleze funcția dvs , trebuie să o faceți după definirea funcției PowerShell trebuie să vadă funcția înainte de a o putea rula, așa că adesea veți stivui toate funcțiile în partea de sus a fișierului și apoi veți rula una sau mai multe la sfârșitul fișierului Nici aprovizionarea cu puncte și nici funcția de rulare a scriptului nu este adecvată în afara testării Ceea ce ar fi mai bine este să oferiți o modalitate definită de a încărca script-ul (și funcțiile acestuia) în memorie, să permiteți ca anumite funcții să fie rulate la cerere și, de asemenea, să oferiți o modalitate de a le elimina rapid și ușor pe toate din memorie, dacă este necesar Acest fel se numește modul și, în cele din urmă, vă vom arăta cum să vă transformați scriptul într-unul singur Nu este dificil, dar avem câteva lucruri pe care vrem să le acoperim mai întâi Până când se întâmplă acest lucru, vă sugerăm să utilizați tehnica pe care tocmai v-am arătat-o - cereți scriptului să ruleze funcția WMI este un instrument de management excelent și de care credem că producătorii de instrumente profită adesea Folosind noile cmdlet-uri CIM, scrieți o funcție pentru a interoga un computer și a găsi toate Serviciile printr-o combinație de mod de pornire, cum ar fi Auto sau Manual, și starea curentă, de exemplu, Running Scopul realizării instrumentelor este de a rămâne flexibil și reutilizabil fără a fi nevoie să editați în mod constant scriptul Ar trebui să aveți deja un început bazat pe exemplele din acest capitol Pentru al doilea laborator, uitați-vă la acest script: Funcția Get-Disklnfo { Param ([șir]$computername='localhost',[int]$MinimumFreePercent= ) $disks=Get-WmiObject -Class Win Logicaldisk -Filter "Drivetype= " foreach ($disk în $disks) {$perFree=($ disc FreeSpace/$disk Size)* ; dacă ($perFree -ge $MinimumFreePercent) {$OK=$True} else {$OK=$False};$disk|Selectați DeviceID,VolumeName,Size,FreeSpace,' ®{Name="OK";Expression={$OK}} }} Obține-Disklnfo Destul de greu de citit și de urmărit, nu-i așa? Luați fișierul de pe site-ul MoreLunches, deschideți-l în ISE și reformatați-l pentru a fi mai ușor de citit Nu uitați să verificați dacă funcționează La fel ca și capitolul anterior, acest capitol poate fi un pic de reîmprospătare Dar pentru că conceptul de domeniu continuă să-i provoace pe oameni, considerăm că merită timpul nostru și al tău să ajungi pe aceeași pagină Mai mult ca sigur, proiectele dvs de fabricare a uneltelor vor fi pe o latură complexă, iar dacă nu înțelegeți scopul, puteți ajunge să aveți un instrument prost Scope este un sistem de containerizare În unele sensuri, este conceput pentru a ajuta la prevenirea conflictelor între diingurile din PowerShell De exemplu, dacă ați rulat un script care definește o variabilă numită $x, ați fi destul de supărat dacă un alt script ar folosi și $x și ți-a stricat cumva scriptul Scope este o modalitate de a construi ziduri între și în jurul diferitelor Scripturi și funcții, astfel încât fiecare are propriul său mic sandbox în care să se joace fără teama de a încurca altceva Există mai multe elemente în cadrul PowerShell care sunt afectate de domeniul de aplicare: Variabile Funcții Aliasuri PSDrives PSSnapins (dar în mod ciudat nu module - așa că tiiing-urile migrează în principal către module și departe de PSSnapins, tiiis nu va conta mult) Shell-ul în sine este un domeniu de aplicare de nivel superior sau global Aceasta înseamnă că fiecare nouă fereastră Power Shell pe care o deschideți este un domeniu de aplicare global complet nou, de sine stătător, fără conexiune cu niciun alt domeniu global ISE vă permite să aveți mai multe domenii globale în aceeași fereastră, ceea ce poate fi puțin confuz În ISE, când selectați Admin'sralO': W dcws Power She el ISE ftîe Edrt View Tc^s Debug Add-ors heip ш >■ \script ps! În scenariu; var este „bună ziua!” Rularea funcției În funcție; var conține „bună ziua!” În funcție; var este acum „la revedere!” Funcția este realizată În scenariu; var este acum „bună ziua!” Vă rugăm, cu siguranță rulați acest script pe cont propriu - vrem să faceți acest lucru vezi rezultatele cu adevărat, chiar în fața ochilor tăi Va face totul mai clar Citiți rezultatul scriptului Observați că la începutul scriptului, $var conține salut! pentru că diat este ceea ce a stabilit prima linie din scriptul Apoi funcția rulează și vede că $var conține salut! Acest lucru se datorează faptului că $var nu există în domeniul de aplicare al funcției, așa că atunci când încearcă să acceseze $var, PowerShell merge până la părintele domeniului de aplicare Iată, tiiere's a $var tiiere! Deci asta vede funcția Dar funcția tiien tiie atribuie la revedere! la $var PowerShell vede că tiiat $var încă nu există în domeniul de aplicare al funcției, așa că creează variabila și pune la revedere! în ea Acum există două copii ale lui $var care rulează: una în domeniul de aplicare al funcției și una — care încă conține Hello! — în domeniul de aplicare al scriptului Domeniul global de aplicare este încă necunoscut despre oricare dintre acestea; tiiere nu are $var în domeniul său de aplicare și nu poate vedea variabilele domeniului său copil Regula de bază este următoarea: dacă încercați să creați sau să schimbați ceva în propriul domeniu de aplicare, acesta este creat în domeniul dvs Rulați New-Al las în interiorul unei funcții, de exemplu, și alias-ul va fi creat numai în acel domeniu Dacă încercați să accesați (adică să citiți) ceva și nu există deja în domeniul curent, PowerShell va merge la domeniul părinte și părintele său și părintele său și așa mai departe, până când va găsi ceva Dacă nu-l ține, elementul tiien cu adevărat nu există și veți primi un mesaj de eroare, sau o valoare nulă sau orice este potrivit pentru genul de lucru pe care îl accesați Dar PowerShell are câteva tehnici pentru a lucra cu elemente care nu sunt incluse Există două tehnici, pe care le caii pe calea lungă și pe cea scurtă Ne vom uita mai întâi la forma lungă Toate cmdlet-urile tiie care se ocupă cu elementele în domeniu au un parametru - scope, care vă permite să lucrați explicit cu articole într-un domeniu diferit Parametrul ia unul dintre cele două tipuri de valori: Un număr, unde zero ( ) reprezintă domeniul curent, este părintele tău, este părintele părintelui tău și așa mai departe Un cuvânt: Local, adică sfera actuală; Script, adică domeniul de aplicare al scriptului care este cel mai apropiat de tine în ierarhie; sau Global, care se referă la domeniul de aplicare de nivel superior al shell-ului Valoarea implicită este sau Locală Deci, dacă ar fi să scrieți o funcție, ați făcut asta Variabilă nouă - Culoare nume - Valoare Violet - Domeniu de aplicare ai crea o variabilă numită $Color, ai seta la Purple și ai face acest lucru în domeniul de aplicare al scriptului părinte — nu în cadrul funcției în sine Veți găsi parametrul tiie -Scope pe toate cmdlet-urile tiie folosind substantivul variabil, pe New-Alias și așa mai departe Modul scurt este conceput numai pentru variabile și implică adăugarea Global, Script sau Local Folosind-o arată ca tiiis: $global:color = „violet” Aceasta ar crea sau seta o variabilă globală numită $color, setând-o să conțină violet, indiferent unde a fost executată comanda tiiis Chiar dacă ar fi executat într-un domeniu de aplicare profund imbricat, ar modifica domeniul de aplicare de nivel superior Comenzi precum New-Variable și New-Alias au, de asemenea, un parametru -Option Setarea tiiis la AllScopes face ca variabila sau aliasul să fie creat în toate domeniile copil create din acel moment în cadrul acelei sesiuni shell Elementul nu este adăugat retroactiv în niciun domeniu secundar existent, dar va fi adăugat, automat, în orice domeniu nou Aceste domenii pot apoi modifica elementul în orice mod doresc, fără a afecta сору a articolului din orice alt domeniu PowerShell oferă un cmdlet numit Set-StrictMode, care configurează unele opțiuni care afectează modul în care funcționează domeniul Există două moduri stricte, vl O și v Nu sunt diferențele: În modul vl O, dacă încercați să accesați o variabilă care nu există în domeniul dvs sau în orice domeniu părinte, veți primi o eroare Excepția este o variabilă cuprinsă între ghilimele duble, care va fi tratată ca un șir gol În modul v , dacă încercați să accesați o variabilă care nu există în domeniul dvs sau în orice domeniu părinte, veți obține o eroare - chiar dacă variabila die este între ghilimele duble De asemenea, dacă încercați să accesați proprietăți inexistente ale unui obiect, veți primi o eroare De asemenea, puteți utiliza parametrul die -Of f pentru a opri complet modul strict Merită să citiți ajutorul pentru Set-StrictMode pentru a afla ceva mai multe despre ce poate face Regula de bază este „Nu încurca în sfera altor persoane ” Este o idee proastă Nu poți ști niciodată ce efecte persistente, în cascadă, vor avea modificările acestor schimbări Din același motiv, nu vă bazați pe obiectivele altor oameni Oamenii Odier sunt atât de nesiguri! Nu accesați nicio variabilă căreia nu i-ați atribuit o valoare chiar în propriul domeniu de aplicare - în felul acesta, veți ști întotdeauna ce conține Aceste reguli nu se aplică alias-urilor încorporate care sunt livrate cu PowerShell: deși alias-uri precum Dir există în domeniul global, este permis să utilizați diem într-un script sau funcție, deoarece este întotdeauna acolo și este întotdeauna definit ca aceeași Este de încredere, pentru că este „în cutie” Suntem deosebit de iritați când vedem oameni care scriu Scripturi care aruncă informații într-o variabilă $global: pentru a transmite informații de la o funcție la anotiier E o idee proastă, proastă Nu puteți garanta întotdeauna că domeniul dvs global va fi păstrat între apeluri (desigur, aplicația gazdă PowerShell de bază o va face, dar este posibil să nu rulați întotdeauna în tiiat) Există modalități adecvate de a trece date între funcții, iar noi vă vom arăta cum să le faceți Tastarea $global înseamnă că o faci greșit, greșit, greșit Acest script ar trebui să creeze câteva PSDrive noi bazate pe variabile de mediu precum %APPDATA% și %USERPROFILE%\DOCUMENTS Dar după script-uri, unitățile nu există De ce? Ce schimbări ați face? Funcția New-Drives { Param() New-PSDrive -Name AppData -PSProvider FileSystem -Root $env:Appdata New-PSDrive -Name Temp -PSProvider FileSystem -Root $env:TEMP $mydocs=Join-Path -Path $env:userprofile -ChildPath Documents New-PSDrive -Name Does -PSProvider FileSystem -Root $mydocs } Unități noi DIR temp: | măsură-obiect -proprietate lungime -sumă Acum sunteți gata să începeți să construiți un instrument practic, din lumea reală Vom crea un instrument de inventar numit Get-Systemlnfo, iar în următoarele capitole vom continua să construim pe el Fiecare capitol va aborda un nou aspect al instrumentului matriță, de la funcționalitatea de bază până la gestionarea erorilor, depanare și ambalarea instrumentului pentru distribuție Fiecare capitol vă va oferi, de asemenea, o serie de laboratoare practice Completarea tuturor poate dura mai multe ore pe care le-ați alocat pentru lectura la prânz, dar vă încurajăm să vă acordați timp suplimentar, dacă puteți, pentru a finaliza fiecare dintre laboratoare Repetarea este o parte importantă a cimentării noilor cunoștințe, iar fiecare laborator va oferi o întorsătură ușor diferită subiectului, pentru a vă ajuta să vă construiți experiența și să vă pregătiți pentru realizarea de instrumente în lumea reală Avem de făcut o mărturisire Când am început să citim această carte, aveam de gând să ne lansăm direct în chestii de gata Asta este de fapt în următorul capitol Vedeți, planul nostru inițial a fost să pătrundem și să murim după ce totul s-a terminat, pentru a explica filozofia noastră de design Unul dintre recenzenții noștri timpurii a sugerat, foarte politicos, că eram proști Am vrut doar să ajungem la lucrurile distractive, dar recenzentul a avut dreptate: trebuie să explicăm de ce vom face ceea ce vom face Știm că este ușor să treceți peste aceste chestii de filozofie Dar intenționăm să rămânem succint și să ajungem la capăt — și, sincer, lucrurile astea sunt importante Oamenii se luptă cu adevărat să facă PowerShell să moară corect, iar sinceritatea ajung să lucreze mult mai mult de care au nevoie, pentru că nimeni nu vrea să acopere liniile directoare de bază de proiectare Deci iată-ne Iată un chiriaș de bază al unui design bun al instrumentului PowerShell: faceți o singură piesă și faceți-o bine În linii mari, o funcție ar trebui să facă una - și numai una - dintre aceste legături: Preluați date de undeva Prelucrarea datelor Trimiteți date într-un loc Puneți datele într-un format vizual destinat consumului uman Acest lucru se potrivește bine cu convenția de denumire a comenzilor din PowerShell: Dacă funcția dvs folosește verbul Get, asta ar trebui să facă: get Dacă emite date, le denumiți cu un verb precum Export, sau Out, sau altceva Dacă fiecare comandă (bine, funcție) se preocupă doar de una dintre aceste legături, atunci vor avea flexibilitatea maximă posibilă De exemplu, să presupunem că vrem să scriem un instrument care să preia câteva informații cheie ale sistemului de operare de pe mai multe computere și apoi să afișăm acele informații într-un tabel frumos formatat pe ecran Ar fi ușor să scrii acel instrument, astfel încât să deschidă Active Directory, să obțină o grămadă de nume de computere, să interogheze informațiile de la ele și apoi să formateze un tabel frumos ca rezultat Problema? Ei bine, dacă mâine nu am vrut datele pe ecran, dar Radier le-ar fi vrut într-un fișier CSV? Ce se întâmplă dacă odată ar fi trebuit să interogăm o mică listă de computere mai mari decât o grămadă de computere din directorul die? Schimbarea Eidier ar implica modificări de codare, ceea ce duce probabil la multe versiuni diferite ale instrumentului nostru Dacă l-am fi făcut mai modular și am urmat filozofia de bază pe care tocmai am descoperit-o, nu ar fi trebuit să facem asta În schimb, s-ar putea să fi proiectat matrița următoare: O funcție tiiat primește nume de computer din directorul tiie O funcție care acceptă numele computerelor, interogează computerul și produce datele dorite O singură funcție permite formatarea datelor într-un tabel frumos de pe ecran Brusc, totul devine mai flexibil Această funcție de mijloc ar putea funcționa acum cu orice sursă de nume de computer: directorul, un fișier text sau orice altceva Datele sale ar putea fi trimise la orice altă comandă pentru a produce rezultate Poate că l-am conecta la Export -CSV pentru a face un fișier CSV tiiat sau la ConvertTo-HTML pentru a face o pagină HTML Dar masa de pe ecran pe care o dorim acum? Parimăm că Format-Table ar putea face treaba, ceea ce înseamnă că nici măcar nu trebuie să scriem acea a treia funcție – mai puțin lucru pentru noi! Deci, să vorbim despre designul funcției Vom sugera că există trei categorii diferite de funcții sau instrumente: intrare, funcțional și ieșire Instrumentele de introducere sunt funcții pe care le scrieți, care nu produc ele însele vreun util inerent, dar sunt mai mult menite să transmită informații unui al doilea instrument Deci, o funcție care preia numele computerelor dintr-o bază de date de gestionare a configurației este un instrument de introducere Nu doriți neapărat nume de computer, dar poate fi o varietate nesfârșită de instrumente suplimentare cărora doriți să le trimiteți nume de computer, inclusiv orice număr de comenzi PowerShell încorporate! Acesta este un bun exemplu despre cum să trasați o linie între funcțiile dvs Să presupunem că scrieți o serie de comenzi menite să preia numele computerelor din baza de date de gestionare a configurărilor Intenția dvs de astăzi este să interogați unele informații WMI de la acele computere, dar nu există alte instrumente care au nevoie de nume de computer ca intrare? Sigur! Restart-Computer acceptă numele computerelor La fel și Get-EventLog și Get-Process și Invoke-Command și încă o duzină de comenzi Acesta este ceea ce sugerează - cel puțin pentru noi - că funcționalitatea obținerii-nume-de-tiie-bază de date ar trebui să fie un instrument de sine stătător: ar putea alimenta mult mai mult decât nevoia actuală de astăzi PowerShell vine deja cu o serie de instrumente de introducere Ținând cont de faptul că obțineți nume de computere, puteți utiliza Import-CSV, Get-Content sau Get-ADComputer pentru a prelua numele computerelor din diverse surse Pentru noi, acest lucru subliniază faptul că sarcina de a obține nume de computer este capacitatea sa proprie, de sine stătătoare, mai degrabă decât să fie parte a unui alt instrument Acesta este genul de instrument pe care îl veți scrie cel mai des Ideea este că acest tip de instrument nu petrece timp regăsind orice informație de care are nevoie pentru a-și face treaba principală În schimb, acceptă acea informație printr-un parametru de vreun fel - parametrul fiind alimentat de date introduse manual, prin comandă anotiier și așa mai departe Deci, dacă instrumentul tău funcțional va interoga informații de la computerul de la distanță, atunci nu face nimic intern pentru a obține numele acelor computere, ci le acceptă pe un parametru Nu-i pasă de unde provin numele de computere - asta e treaba altcuiva Odată ce i s-au dat informațiile de care are nevoie pentru a funcționa, un instrument funcțional își face treaba și apoi scoate obiecte în conductă Mai exact, scoate un singur tip de obiect, astfel încât toate rezultatele sale sunt consecvente De asemenea, acest instrument funcțional nu își face griji cu privire la ceea ce intenționați să faceți cu acea ieșire: pune doar obiecte în conductă Acest tip de instrument nu petrece o nanosecundă îngrijorându-se cu privire la formatare, cu privire la fișierele de ieșire sau cu orice altceva Își face treaba, poate produce unele obiecte ca ieșire și asta e Rețineți că nu toate instrumentele funcționale vor produce rezultate de orice fel O comandă tiiat doar face ceva - poate reconfigurarea unui computer - ar putea să nu producă nicio ieșire, în afară de mesajele de eroare dacă ceva nu merge bine Asta e fme Instrumentele de ieșire sunt special concepute pentru a prelua date - sub formă de obiecte - care au fost produse de un instrument funcțional și apoi a pune datele într-o formă finală Să subliniem tiiat: formă finală Am căutat final în dicționarul nostru și scrie ceva de genul „aferent sau vine la sfârșit; ultima în loc, ordine sau timp ” Cu alte cuvinte, odată ce ați trimis datele către un instrument de ieșire, ați terminat cu el Nu vrei să se întâmple nimic altceva cu datele Doriți să îl salvați într-un fișier sau într-o bază de date sau să îl afișați pe ecran, sau să îl trimiteți prin fax cuiva sau să îl atingeți în cod Morse, indiferent Verbele PowerShell pentru aceasta includ Export, Out și ConvertTo, pentru a numi câteva Luați în considerare inversul acestei filozofii: dacă aveți un instrument care pune date într-o formă finală, cum ar fi un fișier text sau un afișaj pe ecran, atunci acel instrument nu ar trebui să facă altceva Wliy? Ei bine, luați în considerare o funcție pe care am creat-o, numită Get-ComputerDetails Această funcție merge și obține o buneii de informații de la o buneii de computere Apoi produce un tabel frumos, formatat pe ecran Acesta este un afișaj bazat pe text Făcând acest lucru înseamnă că nu am putea niciodată să facem asta: Get-ComputerDetails | Unde OSBuildNumber -le | Sortează ComputerName | ConvertTo-HTML | Out-File computers html Nu am putea face asta? Deoarece, în acest exemplu, Get-ComputerDetails produce text Where-Object, Sort-Object și ConvertTo-HTML nu se pot ocupa de text - se ocupă de obiecte Get-ComputerDetails a pus datele noastre în forma sa finală, ceea ce înseamnă, conform dicționarului, că Get-ComputerDetails „vine la sfârșit” și ar trebui să fie „ultimul pe loc” Nimic nu poate veni după el, ceea ce înseamnă că avem mai puțină flexibilitate Un design mai bun ar fi avut ca Get-ComputerDetails să producă doar obiecte și să creeze o a doua comandă, poate numită Format-MyPrettyDisplay, care se ocupă de formatarea matrițelor În acest fel, am putea obține rezultatul dorit inițial: Get-ComputerDetails | Format-MyPrettyDisplay Dar am putea face și asta Get-ComputerDetails | Unde OSBuildNumber -le | Sortează ComputerName | ConvertTo-HTML | Out-File computers html , ceea ce înseamnă că ne-am putea răzgândi cu privire la utilizarea Format-MyPrettyDisplay din când în când, trimițând în schimb obiectele noastre de date către alte comenzi pentru a produce diferite afișaje, filtrarea datelor, sursa datelor, crearea fișierelor etc pe În aceste laboratoare, nu vă vom pune să scrieți Scripturi sau funcții reale În schimb, dorim să vă informați despre aspectul designului, pe care mulți oameni trec cu vederea Să presupunem că vi s-a cerut să dezvoltați următoarele instrumente PowerShell Chiar dacă instrumentele vor rula din PowerShell , nu trebuie să presupuneți că orice computer la distanță rulează PowerShell Să presupunem că cel puțin PowerShell v Proiectați o comandă tiiat va prelua următoarele informații de la unul sau mai multe computere la distanță, folosind clasele și proprietățile WMI indicate: Win ComputerSystem: Grup de lucru AdminPasswordStatus; afișați valorile numerice ale proprietății tiiis ca șiruri de text Pentru , afișați Dezactivat Pentru , afișați Activat Pentru , afișați NA Pentru , afișați Necunoscut Model Producător Din Win BIOS Număr de serie Din Win OperatingSystem Versiune ServicePackMaj sau Versiune Ieșirea funcției dvs ar trebui să includă și numele fiecărui computer Asigurați-vă că designul funcției dvs include o modalitate de a înregistra erorile într-un fișier text, permițând utilizatorului să specifice un nume de fișier de eroare, dar implicit la C:\Errors txt De asemenea, planificați din timp pentru a crea o vizualizare personalizată, astfel încât funcția dvs să scoată întotdeauna un tabel, folosind următoarele antete de coloană: Numele calculatorului Grup de lucru AdminPassword (pentru AdminPasswordStatus în Win ComputerSystem) Model Producător BlOSSerial (pentru SerialNumber în Win BIOS) OSVersion (pentru versiunea din Win OperatingSystem) SPVersion (pentru ServicePackMaj sauVersion în Win OperatingSystem) Din nou, nu scrii scenariul, ci doar știi ce ai putea face Proiectați un instrument care va prelua clasa WMI Win Volume de la unul sau mai multe computere la distanță Pentru fiecare computer și volum, funcția ar trebui să scoată numele computerului, numele volumului (sucii ca C:\) și spațiul liber și dimensiunea volumului în GB (folosind cel mult două zecimale) Includeți numai volumele care reprezintă hard disk-uri fixe - nu includeți unități optice sau de rețea în ieșire Rețineți că orice computer poate avea mai multe hard disk-uri; ieșirea funcției dvs ar trebui să includă un obiect pentru fiecare disc Asigurați-vă că designul funcției dvs include o modalitate de a înregistra erorile într-un fișier text, permițând utilizatorului să specifice un nume de fișier de eroare, dar implicit la C: Errors lxl De asemenea, planificați să creați o vizualizare personalizată în viitor, astfel încât funcția dvs să producă întotdeauna un tabel, folosind următoarele antete de coloană: Numele calculatorului Conduce Spatiu liber mărimea Proiectați o comandă care va prelua toate serviciile care rulează pe una sau mai multe com putere la distanță Această comandă va oferi opțiunea de a înregistra numele computerelor eșuate într-un fișier text Acesta va produce o listă care include numele fiecărui serviciu care rulează și numele afișat, împreună cu informații despre procesul care reprezintă fiecare serviciu care rulează Aceste informații vor include numele procesului, dimensiunea memoriei virtuale, utilizarea maximă a fișierelor de pagină și numărul de citiri Dar utilizarea maximă a fișierelor de pagină și numărul de citiri nu vor fi afișate în mod implicit Pentru fiecare instrument, gândiți-vă la următoarele întrebări de proiectare: Care ar fi un nume bun pentru instrumentul tău? De ce fel de informații aveți nevoie pentru fiecare instrument? (Aceștia ar putea fi parametri potențiali ) Cum credeți că ar fi rulat instrumentul dintr-un prompt de comandă sau ce tip de date va scrie în conductă? PowerShell are o serie de tipuri de funcții: funcții de bază care returnează doar o valoare, funcții de filtrare care funcționează în conductă și așa mai departe Vom sări direct pentru a ajunge la vârful lanțului trofic și vom construi o funcție avansată - ceea ce unii oameni numesc un cmdlet de script Sincer, credem că aici ar trebui să țintiți pentru orice instrument pe care îl construiți, chiar dacă este doar un instrument pentru uzul dvs personal Funcțiile avansate vă fac o mulțime de sarcini, oferindu-vă o mulțime de funcționalități, în esență, gratuit Puteți ajunge să echivalați cu un cmdlet fără a fi programat în Visual Studio Dacă aveți un fundal de programare, acest lucru vă va cere să ajungeți în mintea dvs , să găsiți tot ce știți deja despre funcții și să ștergeți acele informații - sau cel puțin să le uitați cu voință pentru o vreme Funcțiile PowerShell sunt o bestie diferită, mai ales dacă le construiți pentru a profita cu adevărat de funcționalitatea PowerShell Rămâneți cu noi prin capitolele din această parte a cărții, pentru că, pas cu pas, vă vom arăta cum să construiți ceva cu adevărat minunat La sfârșitul zilei, toate funcțiile avansate ajung să arate remarcabil de similare, așa că avem tendința de a începe cu un șablon de unul Este în lista următoare și este un bun punct de plecare oricând trebuie să construiți un instrument pentru a face orice The function dedaration The function dedarationfuncția { [CmdletBinding()] param( ,, Parametrii de intrare începe {} { [CmdletBinding()] param( [șir [] ] ȘComputerName, [șir]ȘErrorLog ) ÎNCEPE {} PROCES {} SFÂRŞIT { } } Nu am făcut multe, dar stabilim un model de bune practici, așa că haideți să discutăm câteva aspecte specifice a ceea ce tocmai am făcut: Lui PowerShell nu îi pasă de mucii majuscule și minuscule, dar ne place codul ușor de citit, așa că am avut grijă să introducem frumos numele parametrilor -ComputerName ne arată mai bine tiian -computername, iar PowerShell va prezenta parametrul exact așa cum l-am tastat Am declarat un tip de date pentru fiecare parametru În cazul lui -ComputerName, este un [șir [ ] ], iar acele paranteze pătrate suplimentare după g indică faptul că poate accepta una sau mai multe valori -ErrorLog are nevoie de un singur șir, așa că nu primește paranteze suplimentare Parametrii sunt o listă separată prin virgulă Am fi putut introduce întregul bloc de parametri pe o singură linie, astfel încât virgulă după -parametrul -ComputerName îl separă de parametrul următor, -ErrorLog Ne place să punem fiecare parametru pe propria linie și ne place mai ales să punem o linie goală între ele Lui PowerShell nu-i pasă, dar din nou, ne place codul ușor de citit Acea linie goală suplimentară ne va face viața mult mai ușoară, pe măsură ce vom începe să adăugăm mai târziu funcții Observați că am indentat conținutul blocului Param () Vom continua să vă batem cu privire la formatare — este important! O mare parte din ceea ce ne concentrăm în acest moment este doar formatare destul de bună Acest lucru poate părea meschin și enervant pentru tine, dar te rugăm să ai încredere în noi Formatarea este importantă Lui Don îi place să le spună oamenilor: „Dacă nu poți fi deranjat să-ți formatezi scriptul frumos, meriți toate erorile pe care le primești ” Este adevărat: depanarea – și chiar prevenirea erorilor în primul rând – este mult mai ușoară atunci când îți păstrezi formatarea îngrijită și ordonată În plus, dacă scenariul tău este urât, toți copiii tari vor arăta spre tine și vor râde Să nu facem nici un pas fără a testa ceea ce am făcut Acest lucru va implica ceea ce putem spune codul, adică vom introduce niște comenzi pe care le vom șterge aproape imediat Ideea este să ne asigurăm că funcția noastră funcționează corect Lista arată revizuirea — și rețineți că am adăugat câteva comenzi în partea de jos a scriptului care va rula de fapt funcția În acest fel, așa cum am discutat în capitolul , putem rula script-ul tiie în ISE pentru a-l testa Observați, de asemenea, că în final am dat funcției noastre un nume real funcția Get-Systemlnfo { [CmdletBinding()] param( [șir [] ] $ComputerName, [șir]$ErrorLog ) ÎNCEPE {} PROCES { Scrie-Ieșire $ComputerName Scrie-Ieșire $ErrorLog } SFÂRŞIT { } } Get-Systemlnfo -computername one,two,three -errorlog x txt Get-Systemlnfo one x txt Iată rezultatul scriptului când îl rulăm: PS C:\> C:\test ps! unu Două Trei X txt unu X txt Ne așteptăm să urmărești, așa că asigură-te că poți alerga scriptul și obțineți rezultate identice Dacă nu puteți, opriți-vă și reparați-l înainte de a continua Deci știm că variabilele noastre de parametri acceptă intrare și le putem afișa conținutul din blocul PROCESS al funcției Acum este timpul să curățăm codul de testare, așa că vom continua cu funcția prezentată în lista următoare funcția Get-Systemlnfo { [CmdletBinding()] param( [șir[]]$ComputerName, [șir]$ErrorLog ) ÎNCEPE {} PROCES { } SFÂRŞIT { } } Acum suntem gata să facem lucrul acesta să funcționeze Amintiți-vă de la începutul acestui capitol că avem două situații posibile de rezolvat: Dacă obiectele sunt introduse în funcția matriță, blocul PROCESS se va executa de mai multe ori Deoarece intenționăm să introducem numele computerelor, asta înseamnă că $ComputerName va conține doar un nume de computer de fiecare dată când se execută PROCESS Dacă datele sunt furnizate numai prin intermediul parametrilor funcției, PROCESS se va executa o singură dată Pentru noi, tiiat înseamnă $ComputerName ar conține o colecție de mai multe nume de computer atunci când PROCESS se execută Încă nu am conectat lucrurile pentru a accepta nici măcar intrarea în conductă, dar intenționăm să o facem, pentru că așa am spus în designul nostru Deci trebuie să înțelegem că $ComputerName poate conține un singur nume sau poate conține mai multe nume Nu putem ști, așa că trebuie să scriem funcția pentru a face față oricărei situații Aceasta este o preocupare comună atunci când scrieți funcții avansate care acceptă intrarea canalului Din fericire, tiiere este o modalitate ușoară de a o rezolva: vom presupune întotdeauna că $ComputerName conține mai multe nume Construcția ForEach de la PowerShell poate fi folosită pentru a le enumera, astfel încât trebuie să ne ocupăm doar de unul câte unul Dacă $ComputerName se dovedește că uneori contamează doar un nume, este în regulă — ForEach va enumera în continuare acel nume, așa că codul nostru va funcționa bine Următoarea listă arată funcția noastră modificată - observați că am adăugat un pic mai mult cod de aruncat, astfel încât să putem testa rapid funcția funcția Get-Systemlnfo { [CmdletBinding()] param( [șir [] ] $ComputerName, [șir]$ErrorLog ÎNCEPE { Scrie-Ieșire „Numele jurnalului este $errorlog” PROCES { foreach ($computer în $computername) { Scrie-Ieșire „numele computerului este Școmputer” Sfârşit Get-Systemlnfo -ComputerName unu, doi, trei -ErrorLog x txt Acum hai să-l rulăm: PS C:\> i Log name computer computer computer PS C:\> i Log name computer computer computerO:\test psl: este x txt one two three one two threeNume Nume Nume Nu sunt câteva lucruri la care să acordați atenție: PowerShell va prezenta numele parametrilor noștri așa cum au fost definite în blocul Param (), așa că acolo am avut grijă să le introducem frumos (ComputerName versus computername, de exemplu) În altă parte a scriptului nu ne interesează și nici PowerShell, așa că suntem puțin mai leneși, folosind doar $computername și $errorlog Observați trucul cu nume de variabile între ghilimele duble, care ne permite să ne verificăm rapid munca fără a fi nevoie să concatenăm șiruri sau altceva Testăm în mod explicit ideea că blocul BEGIN se execută o singură dată și puteți vedea în rezultatul nostru că am confirmat-o: Numele jurnalului este x txt apare o singură dată, la începutul ieșirii Formatare, formatare, formatare! Conținutul construcției ForEach — totul în parantezele sale {} — este indentat Momentan, acesta este doar un rând, dar am indentat cu respect Conținutul blocurilor BEGIN și PROCESS este de asemenea indentat Observați cât de ușor este să vedeți vizual ce conține fiecare bloc, deoarece conținutul este uniform aliniat Bine, acum este timpul să facem un salt mare și să adăugați comenzile care vor face de fapt ceea ce ar trebui să facă această funcție Verificați această listă funcția Get-Systemlnfo { [CmdletBinding()] param( [șir[]]$ComputerName, [șir]$ErrorLog ) ÎNCEPE { Scrie-Ieșire „Numele jurnalului este $errorlog” } PROCES { foreach ($computer în $computername) { $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer } } SFÂRŞIT { } } Există din nou backtick-ul de trei ori în funcție, în principal pentru a putea încadra codul în paginile tipărite ale cărții Vom repeta avertismentul de mai devreme: asigurați-vă că tastatura înapoi este urmată imediat de o întoarcere la cărucior și nu de spații sau file sau orice altceva Alternativ, pur și simplu nu includeți backtick-ul, nu apăsați Enter și string die întreaga comandă Get-WmiObject pe o singură linie Rețineți că nu am transmis Get-WmiObject la nimic altceva Chiar dacă intenția noastră este să obținem numai anumite proprietăți de la fiecare dintre aceste obiecte WMI, punem întregul obiect - inclusiv proprietățile nedorite - în trei variabile Tiiere nu are niciun motiv să facă altceva în acest moment Am eliminat cea mai mare parte a codului de aruncat (lăsăm blocul BEGIN pentru moment) și nu îl putem testa din nou în acest moment În primul rând, trebuie să ne construim rezultatul real În acest moment, avem datele noastre WMI stocate în trei variabile Nu le putem scoate doar pe acestea, deoarece ar încălca regula „ieșiți doar un singur tip de obiect” În schimb, trebuie să combinăm biții de informații pe care le dorim într-un singur obiect Următoarea listă arată cum o facem funcția Get-Systemlnf® { [CmdletBinding()] param( [șir[]]$ComputerName, [șir]$ErrorLog ) BEGIN { Write-Output „Numele jurnalului este $errorlog” } PROCES { foreach ($computer în $computername) { $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{ ComputerName =$computer; OSVersion =$os version; SPVersion =$os servicepackmaj orversion; BIQSSerial =$bios seriaInnumber; Producător =$comp producător; Model =$comp model} $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo -ErrorLog x txt -ComputerName localhost,localhost Am îngroșat noile lucruri, inclusiv o nouă linie de cod de aruncat la sfârșitul fișierului script, astfel încât să putem testa acest lucru Am făcut trei lucruri în cadrul funcției în sine: Am creat un tabel hash, care este stocat în $props Având în vedere modul în care intenționăm să folosim acest lucru, sintaxa pentru aceasta este numele proprietății pe care vrem să o creăm, valoarea pe care vrem să o punem în proprietatea și punctul și virgulă Veți observa că am configurat proprietățile exacte pe care le-am decis în designul nostru original și le-am completat cu date din variabilele noastre care conțin obiecte WMI Am creat apoi un nou obiect de tip PSObject, care este un tip special de obiect pe care Microsoft ni-l oferă în acest scop exact Îl punem să populeze noul obiect cu tabelul hash de proprietăți și stocăm noul obiect în $obj Din punct de vedere tehnic, nu a fost nevoie să stocăm un obiect, dar intenționăm să facem mai mult cu asta mai târziu, așa că este mai ușor să îl punem într-o variabilă acum Putem scoate obiectul în conductă folosind Write-Obj ect Hai să-l rulăm Observați că am dat funcției noastre numele computerului localhost de două ori, doar ca să putem testa capacitatea acesteia de a scoate mai multe obiecte Iată rezultatul: PS C:\> C:\test ps! Numele jurnalului este x txt Producător Parallels Software International Inc OSVersion BlOSSerial Parallels-D A C АВ E AF C D FC DC СотриterName SPVersion gazdă locală Model Platformă virtuală Parallels Producător Parallels Software International Inc OSVersion BlOSSerial Parallels-D A C АВ E AF C D FC DC СотриterName SPVersion gazdă locală Model Platformă virtuală Parallels Perfect! Acum vrem să subliniem avantajul tehnicii pe care o folosim Deoarece ieșim un singur tip de obiect în pipeline, prin intermediul Write-Output, putem trimite diat output oriunde dorim Toate comenzile drese ar funcționa: Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo Get-Systemlnfo -comp localhost -comp localhost -comp localhost -comp localhost -comp localhost -comp localhost -comp localhost -comp localhost -comp localhost -comp localhost -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt -errorlog x txt | Export-CSV | ConvertTo-HTML I Export-CliXML | Sort OSVersion | Format-Table | Export-CSV | ConvertTo-HTML I Export-CliXML | Sort OSVersion | Format-Table Vedea? Fără a ne îngrijora cum va fi folosită ieșirea sau cum ar trebui să arate, ne putem trimite ieșirea la comenzile ordr O putem sorta Filtrați-l Formatați-o Exportați-l Transformă-l Nu contează - primim toate opțiunile drose fără programare suplimentară Probabil veți observa că proprietățile noastre nu sunt afișate în ordinea în care le-am creat Este normal: PowerShell afișează proprietățile în mai mult sau mai puțin în orice ordine dorește Există o tehnică pentru păstrarea ordinii proprietăților, dar nu o vom folosi Nu? În cele din urmă, nu va fi nevoie – într-un capitol următor, vom exercita controlul asupra afișajului vizual al rezultatelor noastre Dacă aveți ceva experiență anterioară în programare, puteți începe să încercați să utilizați tiiat pentru a anticipa ce are nevoie PowerShell de dvs Fiți atenți acolo, pentru că este ușor să începeți să alergați pe un drum prost către un loc prost Există câteva activități pe care le vedem adesea elevii: Creați o variabilă matrice, adăugați obiecte personalizate la matrice și apoi la sfârșitul ieșirii scriptului întregul tablou Nu e nevoie să faci tiiis Scopul conductei PowerShell este de a acumula obiecte de ieșire una la o melodie - este matricea dvs de ieșire Doar scrieți obiecte direct în conductă și lăsați PowerShell să-și facă griji Folosiți cuvântul cheie Return pentru a obține rezultate Din nou, nu e nevoie Cuvântul cheie Return de la PowerShell este ceea ce unii oameni consideră zahăr de sintaxă, ceea ce înseamnă că este acolo doar pentru ca oamenii care se așteaptă să fie acolo să îl descopere Return face exact același lucru ca Write-Output, cu excepția faptului că diat Return iese imediat din funcție Fără sens! Utilizați Write-Output pentru a scrie câte un obiect în conductă Funcția va ieși când ajunge la final Luați în considerare întotdeauna scrierea obiectelor în conductă, nu returnarea valorilor Am făcut și ceva ce nu ar trebui Vă amintiți regula, „ieșiți doar un singur tip de obiect”? L-am spart tehnic Acea linie de cod de aruncat din blocul BEGIN folosește Write-Output, care pune un obiect String în pipeline Blocul nostru PROCESS scoate obiecte personalizate în conductă Hopa! Lucrul corect de făcut în acest moment este să eliminați doar codul tiirowaway din blocul BEGIN Tiiere este o modalitate mai bună de a scoate aceste informații, dar încă nu am ajuns acolo Așa că vom lua următoarea listă ca script-ul nostru final pentru acest capitol, care va deveni punctul de plecare pentru următorul capitol funcția Get-Systemlnfo { [CmdletBinding()] param( [șir [] ] $ComputerName, [șir]$ErrorLog ) ÎNCEPE { } PROCES { foreach ($computer în $computername) { $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion =$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Mânufacturer'=$comp manufacturer; „Model”=$comp model} $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo -ErrorLog x txt -ComputerName localhost,localhost Am lăsat ultima linie în script, care rulează funcția noastră Vom testa asta mult mai mult, așa că ar putea la fel de bine să-l lăsăm acolo Asigurați-vă că aveți acest script și că rulează în ISE fără eroare Vom construi pe asta în capitolul următor, așa că este important să fim cu toții pe aceeași pagină Există câteva detalii despre funcția noastră care nu ne place, care oferă o trecere perfectă în capitolul următor În primul rând, trebuie să ne asigurăm că tiiat botii ai parametrilor noștri sunt obligatorii, deși s-ar putea să setăm doar o valoare implicită pentru -ErrorLog, așa că nu trebuie să continuăm să specificăm parametrul tiiat Avem nevoie, de asemenea, de o modalitate mai bună de a verifica valoarea parametrului -ErrorLog, fără a folosi Write-Output (care făcea ca conducta noastră de ieșire să conțină mai multe obiecte) Există, de asemenea, câteva ajustări pe care am dori să le facem De exemplu, nu suntem siguri că tiiat -ComputerName este numele perfect al parametrului Este consistent cu restul Shell, dar avem tendința de a ne gândi mai întâi la cuvinte precum -host, așa că am dori să vedem dacă putem face ca acest lucru să funcționeze De asemenea, ar fi bine să punem câteva limitări instrumentului nostru, astfel încât să poată rula (de exemplu) doar pe un set mic de computere la o melodie Asta va împiedica performanța să scape de sub control Vom aborda majoritatea acestor probleme în capitolul următor Folosind notele de proiectare din capitolul anterior, începeți să vă construiți instrumentele Nu va trebui să abordați fiecare punct de proiectare chiar acum Vom revizui și extinde aceste funcții un pic mai mult în următoarele câteva capitole Pentru acest capitol, funcțiile dumneavoastră ar trebui să se finalizeze fără erori, chiar dacă folosesc doar ieșiri temporare Folosind notele din Laboratorul A din capitolul , scrieți o funcție avansată care acceptă unul sau mai multe nume de computer Pentru fiecare nume de computer, utilizați CIM sau WMI pentru a interoga informațiile specificate Pentru moment, păstrați numele fiecărei proprietăți, folosind ServicePackMajorVersion, Version, SerialNumber și așa mai departe Dar mergeți mai departe și „traduceți” valoarea pentru AdminPasswordStatus în echivalentul text corespunzător Testați funcția adăugând -computerName localhost în partea de jos a scriptului și apoi rulând scriptul (înlocuind cu numele dvs real al funcției, care nu ar include parantezele unghiulare) Ieșirea pentru un singur computer ar trebui să arate cam așa: Workgroup Manufacturer Computername Version Model Workgroup Manufacturer Computername Version Model innotek GmbH CLIENT VirtualBox innotek GmbH CLIENT VirtualBox Parola admin : NA ServicePackMajorVersion: Număr de serie : Este posibil ca unele valori să fie goale Folosind notele pentru Laboratorul В din capitolul , scrieți o funcție avansată care acceptă unul sau mai multe nume de computer Pentru fiecare nume de computer, utilizați CIM sau WMI pentru a interoga informațiile specificate Formatați valorile proprietăților Dimensiune și FreeSpace în GB la două zecimale Testați funcția adăugând -computerName localhost în partea de jos a scriptului dvs și apoi rulând scriptul (înlocuind cu numele real al funcției, care nu ar include paranteze unghiulare) Ieșirea pentru un singur serviciu ar trebui să arate cumva ca tiiis: Spatiu liber Conduce Numele calculatorului mărimea , \\?\Volum{ d f CLIENTUL , , C:\Temp\ CLIENTUL , C:\ CLIENTUL , D:\ CLIENTUL Cântând notele pentru Laboratorul C din capitolul , scrieți o funcție avansată care acceptă unul sau mai multe nume de computer Pentru fiecare nume de computer, utilizați CIM sau WMI pentru a interoga toate instanțele Win Service în care proprietatea State este în execuție Pentru fiecare serviciu, obțineți proprietatea ProcessID Apoi interogați o instanță care se potrivește a clasei Win Process - este, instanța cu același ProcessID Scrieți un obiect personalizat în conductă care include numele serviciului și numele afișat, numele computerului, numele procesului, ID-ul, dimensiunea virtuală, utilizarea maximă a fișierelor de pagină și numărul de fire Testați funcția adăugând -computerName localhost la sfârșitul scriptului (înlocuind cu numele real al funcției, care nu ar include parantezele unghiulare) Ieșirea pentru un singur serviciu ar trebui să arate ceva ca tiiis: Computername ThreadCount ProcessName Name VMSize PeakPageFile Displayname Computername ThreadCount ProcessName Name VMSize PeakPageFile Displayname CLIENT svchost exe wuauserv Windows Update CLIENT svchost exe wuauserv Windows Update Dacă timpul este limitat, puteți sări peste cele trei laboratoare anterioare și să lucrați la un singur laborator independent Scrieți o funcție avansată numită Get-Systemlnfo Această funcție ar trebui să accepte unul sau mai multe nume de computer printr-un parametru -ComputerName Ar trebui să folosească WMI sau CIM pentru a interoga clasa Win OperatingSystem și clasa Win ComputerSystem pentru fiecare computer Pentru fiecare computer interogat, afișați ultima oră de pornire (într-un format standard de dată/ora), numele computerului și versiunea sistemului de operare (toate de la Win OperatingSystem) De asemenea, afișați producătorul și modelul (de la Win СотриterSystem) Ar trebui să ajungeți cu un singur obiect cu toate aceste informații pentru fiecare computer Rețineți că ultima proprietate a orei de pornire nu conține o valoare de dată/ora care poate fi citită de om; va trebui să utilizați metoda ConvertToDateTime () a clasei pentru a converti acea valoare într-o dată/oră cu aspect normal Testați funcția adăugând Get-Systemlnfo -computerName localhost la sfârșitul scriptului Ar trebui să obțineți un rezultat ca acesta: Model Model VirtualBox VirtualBox ComputerName Manufacturer LastBootTime OSVersion ComputerName Manufacturer LastBootTime OSVersion gazdă locală innotek GmbH : : Laboratoarele A, B și C pentru capitolele până la se bazează pe ceea ce sa realizat în capitolele anterioare Dacă nu ați găsit un laborator dintr-un capitol anterior, vă rugăm să faceți acest lucru Apoi verificați rezultatele cu soluții eșantion pe MoreLunches com înainte de a trece la următorul laborator din secvență Odată ce ați început să creați funcții avansate, este ușor să doriți ca acestea să facă din ce în ce mai multe și mai multe În acest capitol, vom duce funcțiile avansate puțin mai departe, adăugându-le o serie de caracteristici utile Vom încerca să obținem cât mai multă funcționalitate posibil pentru cât mai puțină muncă posibil, lăsând PowerShell să facă cea mai mare parte a muncii pentru noi, ceea ce înseamnă că nu va trebui să facem prea multă programare! Vrem să ne asigurăm că comanda noastră are tot ce are nevoie atunci când rulează, ceea ce înseamnă că ar putea fi necesar să solicităm cuiva un nume de computer sau un nume de fișier de jurnal de erori Am furniza o valoare implicită simplă pentru numele fișierului jurnal de erori, dar cu siguranță dorim să solicităm numele computerului respectiv, dacă nu este furnizat unul Din fericire, nu este nevoie de codificare pentru ca acest lucru să se întâmple! Consultați următoarea listă funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True)] [șir [] ] ȘComputerName, [șir]ȘErrorLog = 'c:\retry txt' ) ÎNCEPE { } PROCES { foreach ($computer în $computername) { $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo Tot ce trebuia să facem a fost să adăugăm acea valoare implicită la $ErrorLog și am adăugat un atribut [Parameter () ] la parametrul $ComputerName În cadrul acestui atribut, am indicat că parametrul este obligatoriu Un lucru de care trebuie să fiți conștient este că dacă setați Obligatoriu la $True și furnizați o valoare implicită a parametrului, valoarea implicită va fi ignorată Aici puteți începe să vedeți valoarea liniei goale pe care am inclus-o între cei doi parametri Bitul [Parameter () ] merge numai cu $ComputerName; am putea include și unul cu $ErrorLog, dar acum nu este nevoie Observați că ultima linie a scriptului acum doar apelează funcția fără parametri , astfel încât să putem testa noua noastră configurație Iată ce se întâmplă când rulăm scriptul: PS C:\> C:\test ps! cmdlet Get-Systemlnfo la poziția a conductei de comandă Furnizați valori pentru următorii parametri: ComputerName[ ]: gazdă locală ComputerName[ ]: Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Observați că ni s-a cerut să introduceți ComputerName Deoarece parametrul este configurat să accepte mai multe valori (nu uitați, aceasta este partea [șir [] ]), PowerShell ne-a tot solicitat chiar dacă am introdus o valoare Doar apăsați Enter într-un prompt gol pentru a vă afișa shell-ul pe care ați terminat-o și nu aveți mai multe valori de introdus În capitolul anterior, vă veți aminti că am șters un cod de aruncat din blocul BEGIN al funcției die, deoarece scria un String în pipeline, care a încălcat regula „ieșiți doar un singur fel de obiect” Din fericire, PowerShell oferă o modalitate specifică de a scrie diferite tipuri de mesaje fără a strica rezultatul dorit al instrumentului Dacă scrieți în conductă, putem avea text scris într-un flux alternativ Aruncă o privire la următoarea listă funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True)] [șir [] ] $ComputerName, [șir]$ErrorLog = „c:\retry txt” ) ÎNCEPE { Scrieți-verbose „Jurnalul de erori va fi ȘErrorLog” } PROCES { foreach ($computer în $computername) { Scriere-verboză „Interogare $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion =$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; „Model”=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo -ComputerName gazdă locală Am adăugat utilizări ale lui Write-Verbose Să vedem cum arată tiiat când rulăm scriptul (am modificat ultima linie a scriptului tiie, care apelează funcția, așa că oferim un nume de computer, pentru că nu vrem să ni se mai solicite): PS C:\> C:\test ps! Producator: Parallels Software International Inc Versiune OS: BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Așteptați—unde este rezultatul pronunțat ? Iată partea tare despre Write-Verbose când este folosit într-o funcție avansată: își suprimă propria ieșire în mod implicit Vrei să-l pornești? Rulați scriptul astfel: Get-Systemlnfo -ComputerName localhost -verbose PS C:\> C:\test psl VERBOSE: Jurnalul de erori va fi c:\retry txt VERBOSE: Interogare localhost VERBOSE: Interogări WMI finalizate Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Doar prin adăugarea comutatorului -Verbose, am activat ieșirea Write-Verbose Acum, putem alege să avem acea ieșire afișată sau să o suprimăm, în funcție de nevoile noastre în acest moment Asigurați-vă că urmați acest capitol – vrem să ne asigurăm că aveți o versiune funcțională a acestei funcții pe care o puteți folosi ca exemplu pentru munca dvs de laborator La sfârșitul capitolului anterior, am menționat că un cuvânt precum gazdă ne-a apărut mai ușor în minte decât numele computerului când a fost vorba de parametrul nostru Trebuie să folosim -ComputerName deoarece este în concordanță cu modul în care funcționează restul PowerShell, dar asta nu înseamnă că nu putem avea alte opțiuni Luați în considerare această listă funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True)] [Alias( nume de gazdă )] [șir[]]$ComputerName, [șir]$ErrorLog = „c:\retry txt” ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { foreach ($computer în $computername) { Scriere-verboză „Interogare $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion =$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo -Host localhost -verbose Singura linie nouă este cu caractere aldine Tocmai am adăugat un atribut [Alias ()] la parametrul -ComputerName, astfel încât parametrul poate fi numit și -HostName Deoarece PowerShell încă ne permite să truncăm numele parametrilor (ca un fel de comandă rapidă), pariem că -Host va funcționa și asta, iar asta încercăm acum pe ultima linie a scriptului Iată ce primim când îl rulăm: PS C:\> C:\test psl VERBOSE: Jurnalul de erori va fi c:\retry txt VERBOSE: Interogare localhost VERBOSE: Interogări WMI finalizate Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Perfect! Din nou, aici poate fi utilă linia goală dintre cei doi parametri Pe măsură ce parametrul nostru - СотриterName devine din ce în ce mai complex, separarea vizuală dintre cei doi parametri devine mai importantă În designul nostru original al funcției, am spus că am vrut -ComputerName să accepte șiruri de caractere din conductă Este timpul să se întâmple asta, așa cum se arată aici funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [Alias ('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = „c:\retry txt” ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { foreach ($computer în $computername) { Scriere-verboză „Interogare $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; „Model”=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } localhost , localhost | Get-Systemlnfo Acest lucru a necesitat doar o modificare a atributului nostru [Parameter () ] (afișat cu aldine) și a ultimei linii a scriptului nostru, unde acum trimitem două șiruri de caractere către comandă în loc să specificăm numele computerelor pe parametru Această modificare va prelua toate șirurile care sunt în conductă și le va alimenta parametrul -ComputerName Rularea scriptului produce acum: PS C:\> C:\test psl Producator: Parallels Software International Inc Versiune OS: BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Producator : Parallels Software International Inc OS : BLOSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Minunat - care a funcționat perfect Este destul de frumos să vezi cum rulează PowerShell asta Vom face o modificare minoră, prezentată în lista următoare Vom adăuga doar câteva rezultate mai detaliate De asemenea, rețineți că adăugăm o linie la sfârșitul scriptului, astfel încât să putem testa funcția în modul de intrare pipeline, precum și în modul parametri funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = „c:\retry txt” ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Write-Verbose "Beginning PROCESS block" foreach ($computer in $computername) { Write-Verbose "Interogare $computer" $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion =$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Write-Host " MODUL PIPELINE " „localhostlocalhost” | Get-Systemlnfo -Verbose Write-Host " MOD PARAM " Get-Systemlnfo -ComputerName localhost,localhost -Verbose Iată rezultatul Rețineți că, în mod normal, nu încurajăm utilizarea Write-Host (Don a avut câteva lucruri creative de spus despre el, cel puțin), dar în acest caz îl folosim doar pentru a face rezultatul mai ilustrativ în această carte Mai întâi este rezultatul din modul pipeline: MODUL CONDUCTĂ VERBOSE: Jurnalul de erori va fi c:\retry txt VERBOSE: Începutul blocului PROCES VERBOSE: Interogare localhost VERBOSE: Interogări WMI finalizate Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A АВ E AF D FC DC ComputerName : localhost SPVersiunea : Model : Platformă virtuală Parallels VERBOSE: Începutul blocului PROCES VERBOSE: Interogare localhost VERBOSE: Interogări WMI finalizate Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A АВ E AF D FC DC ComputerName : localhost SPVersiunea : Model : Platformă virtuală Parallels Nu puteți vedea că am intrat în blocul PROCES de două ori, o dată pe computer Acest lucru este în concordanță cu ceea ce am explicat în capitolele anterioare: când direcționați obiecte către un instrument, blocul PROCESS se execută o dată pentru fiecare obiect, iar în cazul nostru parametrul $ComputerName conține de fiecare dată un singur nume de computer Acum pentru modul parametri: MOD PARAM VERBOSE: Jurnalul de erori va fi c:\retry txt VERBOSE: Începutul blocului PROCES VERBOSE: Interogare localhost VERBOSE: Interogări WMI finalizate Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels VERBOSE: Interogare localhost VERBOSE: Interogări WMI finalizate Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels De data aceasta am intrat o singură dată în blocul PROCESS și $ Сотри terName conținea ambele nume Bucla ForEach s-a ocupat de rotirea lor pe rând, astfel încât să putem lucra cu ele individual Deoarece scriptul nostru folosește WMI, are un dezavantaj potențial, legat de faptul că facem trei interogări WMI și facem acest lucru pe fiecare computer, unul câte unul, în secvență Mai simplu spus, acest lucru ar putea dura mult timp pentru a interoga o mulțime de сотри te rs! Pentru a împiedica acest lucru să se întâmple, vom adăuga un atribut de validare, astfel încât PowerShell să accepte doar până la nume de computer Următoarea lista conține modificarea funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True,ValueFromPipeline=$True)] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = „c:\retry txt” ) BEGIN { Write-Verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scrie-verbose „Început blocul PROCES” pentru fiecare ($computer în $computername) { Scriere-verboză „Interogare $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion =$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-Verbose „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Write-Output $obj } } SFÂRŞIT { } } Get-Systemlnfo -ComputerName unu, doi, trei, patru, cinci, șase, șapte, opt, nouă, zece, unsprezece Ultima linie din script va rula exact așa cum a fost tastat Deoarece am încheiat penultima linie cu o virgulă (după valoarea cinci), PowerShell va căuta ca comanda să continue pe a doua linie Este un truc misto! Iată ce se întâmplă când rulăm acel script: PS C:\> C:\test psl Get-Systemlnfo : Nu se poate valida argumentul pentru parametrul „ComputerName” Numărul de argumente furnizate ( ) depășește numărul maxim de argumente permise ( ) Specificați mai puțin de argumente și apoi încercați din nou comanda La C:\test psl: char: + Get-Systemlnfo -ComputerName unu, doi, trei, patru, cinci, șase, șapte, opt, nouă, zece, el + Categorylnfo : InvalidData: (:) [Get-Systemlnfo], ParameterBindingValidationException + FullyQualifiedErrorld: ParameterArgumentValidationError, Get-Systemlnfo Asta e eroarea la care ne așteptam Am evidențiat textul relevant cu caractere aldine pentru confortul dvs Există de fapt o grămadă de alte atribute de validare pe care PowerShell le înțelege: Rulați ajutor despre functions advanced parameters în shell pentru a afla totul despre ele Știi, ni se pare că s-ar putea să nu dorim întotdeauna un fișier jurnal de erori Chiar dacă nu am implementat de fapt crearea acelui jurnal, ne-am dori o modalitate de a-l putea activa sau dezactiva, ca și cum am putea activa sau dezactiva ieșirea verbosă Urmăriți următoarea listă funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scrie-verbose „Început blocul PROCES” pentru fiecare ($computer în $computername) { Scriere-verboză „Interogare $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion =$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Proprietate $props Write-Output $obj Write-Output $obj} } SFÂRŞIT { } } Get-Systemlnfo -ComputerName gazdă locală Nu s-au schimbat multe aici: am adăugat o virgulă după parametrul $ErrorLog, deoarece acum adăugăm un al treilea parametru după el în blocul Param () Noul parametru, pe care utilizatorii îl vor vedea ca -LogErrors, a fost declarat ca tipul [comutator] PowerShell va popula automat variabila $LogErrors cu True dacă comanda este rulată cu -LogErrors și o va popula cu False dacă comanda este rulată fără parametru Deci, implicit acum va fi să nu înregistreze erorile, iar cineva poate adăuga -LogErrors dacă dorește jurnalul Ultimul lucru pe care îl vom face este să adăugăm niște ajutor pentru parametri Acest lucru îi va ajuta pe oameni să înțeleagă ce este menit să facă fiecare parametru, în special parametrul - Сотри terName , care este ceva pentru care li se poate solicita Pentru a revedea un exemplu anterior, iată cum arată promptul pentru parametrul -ComputerName: cmdlet Get-Systemlnfo la poziția a conductei de comandă Furnizați valori pentru următorii parametri: ComputerName[ ]: gazdă locală ComputerName[ ]: Aruncă o privire la această listă, unde am făcut o altă modificare minoră funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Write-Verbose "Beginning PROCESS block" foreach ($computer in $computername) { Write-Verbose "Querying $computer" $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo Acest nou mesaj de ajutor, care face parte din atributul [Parameter () ], poate fi acum afișat de shell atunci când solicită acel parametru Deoarece cei doi parametri nu vor fi niciodată solicitați, nu am creat un mesaj de ajutor pentru diem De asemenea, rețineți că am întrerupt formatarea atributului die [Parameter () ] Deoarece acea moartă devine din ce în ce mai lungă, punerea fiecărei setări pe propria linie face mai ușor de citit și o ajută să se încadreze în cartea lui! Deoarece primele două setări au o virgulă după diem, putem apăsa Enter după virgulă și putem continua cu atributul pe linia următoare Instrumentul nostru începe să arate și să se simtă mult ca o comandă PowerShell „adevărată”, ceea ce ne face din ce în ce mai conștienți de modurile în care nu se comportă încă ca un cmdlet real De exemplu, oricine a învățat să folosească PowerShell în mod eficient știe să folosească sistemul de ajutor al tiie shell, dar funcția noastră nu oferă încă rezultate de ajutor foarte bune Vrem să reparăm tiiat și despre asta vom aborda în capitolul următor În acest capitol, vom construi pe funcțiile pe care le-ați creat în ultimul capitol folosind conceptele pe care sperăm că le-ați preluat astăzi Pe măsură ce lucrați prin aceste laboratoare, adăugați mesaje detaliate pentru a afișa pașii cheie sau informații despre progres Modificați funcția avansată din capitolul , Laboratorul A, pentru a accepta intrarea în conductă pentru parametrul -ComputerName De asemenea, adăugarea unei intrări detaliate va afișa numele fiecărui computer contactat Includeți codul pentru a verifica dacă parametrul -ComputerName nu va accepta o valoare nulă sau goală Testați funcția prin adăugarea „localhost” | -verbose la sfârșitul scriptului Ieșirea ar trebui să arate oarecum ca tiiis: VERBOSE: Pornirea Get-Computerdata VERBOSE: Obținerea datelor de la localhost VERBOSE: Win Computersystem VERBOSE: Win Bios VERBOSE: Win OperatingSystem Grup de lucru innotek GmbH CLIENT VirtualBox NA innotek GmbH CLIENT VirtualBox NA Producător Numele calculatorului Versiune Model Parola administratorului ServicePackMaj sau versiune Număr de serie VERBOSE: Încheierea Get-Computerdata Modificați funcția avansată din capitolul , Laboratorul B, pentru a accepta introducerea conductei pentru parametrul -СотриterName Adăugați o ieșire detaliate care va afișa numele fiecărui computer contactat Asigurați-vă că parametrul -ComputerName nu va accepta o valoare nulă sau goală Testați funcția adăugând „localhost” | -verbose până la sfârșitul scriptului Ieșirea ar trebui să arate cam așa: VERBOSE: Pornirea Get-Volumelnfo VERBOSE: Obținerea datelor de volum de la localhost VERBOSE: Se procesează volum \\?\Volum{ d f - e b-llde-b - e f e }\ Spatiu liber Conduce Numele calculatorului mărimea , \\?\Volum{ d f CLIENTUL , VERBOZĂ: Prelucrare volumul C:\Temp\ , C:\Temp\ CLIENTUL VERBOZĂ: Prelucrare volumul C:\ , C:\ CLIENTUL VERBOZĂ: Prelucrare volumul D:\ , D:\ CLIENTUL VERBOZ: Încheiere Get ■ -Volumelnfo Modificați funcția dvs avansată din Lab C în capitolul pentru a accepta intrarea canalului pentru parametrul -ComputerName Adăugați o ieșire detaliate care va afișa numele fiecărui computer contactat și numele fiecărui serviciu interogat Asigurați-vă că parametrul -ComputerName nu va accepta o valoare nulă sau goală Testați funcția rulând „localhost” | -verbose Ieșirea pentru două Servicii ar trebui să arate cam așa: VERBOSE: Pornirea Get-Servicelnfo VERBOSE: Obținerea de servicii de la localhost VERBOSE: Serviciul de procesare AudioEndpointBuilder Nume computer: CLIENT Număr fire: Nume proces: svchost exe Nume : AudioEndpointBuilder VMS : PeakPageFile: Nume afișat: Windows Audio Endpoint Builder Utilizați acest script ca punct de plecare funcția Get-Systemlnfo { [CmdletBinding()] param( [șir[]]$ComputerName ) PROCES { foreach ($computer în $computerName) { $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $cs = Get-WmiObject -class Win ComputerSystem -computerName $computer $props = @{'ComputerName'=$computer; 'LastBootTime'=($os ConvertToDateTime($os LastBootupTime)); 'OSVersion'=$os version; Manufacturer'=$cs manufacturer; Model'=$cs model} $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } } Modificați această funcție pentru a accepta intrarea canalului pentru parametrul - Сотри terName Adăugați o ieșire detaliate care va afișa numele fiecărui computer contactat Asigurați-vă că parametrul -ComputerName nu va accepta o valoare nulă sau goală Testați scriptul adăugând această linie la sfârșitul fișierului script: „localhostlocalhost” | Get-Systemlnfo -verbose Ieșirea ar trebui să arate cam așa: VERBOSE: Obținerea datelor WMI de la localhost Model Model VirtualBox VirtualBox СотриterName Manufacturer LastBootTime OSVersion СотриterName Manufacturer LastBootTime OSVersion gazdă locală innotek GmbH : : Laboratoarele A, B și C pentru capitolele până la se bazează pe ceea ce sa realizat în capitolele anterioare Dacă nu ați găsit un laborator dintr-un capitol anterior, vă rugăm să faceți acest lucru Apoi verificați rezultatele cu soluții eșantion pe MoreLunches com înainte de a trece la următorul laborator din secvență Veți observa în această carte că fiecare capitol progresiv (prin cel puțin capitolul ) vă va face instrumentele din ce în ce mai bune Ai putea doar să iei ceea ce ai învățat până în acest punct și să te oprești, știind că ai un instrument funcțional, util și bine conceput Dar de ce să te oprești acum când totul devine distractiv? Vom începe să ne concentrăm din ce în ce mai mult pe ca instrumentele dvs să arate, să simtă, să miros și să guste (imaginați-vă asta) din ce în ce mai mult ca un cmdlet PowerShell „adevărat” O modalitate de a face acest lucru este ca instrumentele dvs să includă ajutor care arată exact ca ajutorul pentru cmdleturile native PowerShell Chiar acum, dacă încercăm să cerem sistemului de ajutor asistență cu funcția Get-Systemlnfo, vom obține ceva de genul acesta: NUME Get-Systemlnfo SINTAXĂ Get-Systemlnfo [-ComputerName] [ [-ErrorLog] ] [-LogErrors] [ ] ALIASSE Nici unul OBSERVAȚII Get-Help nu poate găsi fișierele de ajutor pentru acest cmdlet pe acest computer afișează doar ajutor parțial Pentru a descărca și instala fișiere de ajutor pentru modulul care include acest lucru cmdlet, utilizați Update-Help Nu prea util, într-adevăr De fapt, este de-a dreptul greșit, deoarece, în ciuda a ceea ce spune, rularea Update-Help nu va face nimic pentru a oferi funcției noastre un ajutor mai arătos și mai complet Pentru fericire, există o soluție ușoară, prezentată în lista următoare funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Write-Verbose "Beginning PROCESS block" foreach ($computer in $computername) { Write-Verbose "Interogare $computer" $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } ajutor Get-Systemlnfo -full Am adăugat o ultimă linie la acest script care va încerca să afișeze ajutor pentru Get-Systemlnfo Acest lucru vă va permite să testați rulând scriptul în ISE Avem câteva lucruri de subliniat: Ceea ce am adăugat se numește ajutor bazat pe comentarii și puteți citi mai multe despre el rulând help about comment based help în shell Preferăm să punem ajutorul imediat după numele funcției noastre, dar înaintea atributului [CmdletBinding () ], care este una dintre câteva locații valide pentru ajutor și este cea mai ușoară locație de a nu da greșelii Textul de ajutor este cuprins între , care sunt caracterele de blocare a comentariilor PowerShell Ajutorul bazat pe comentarii este împărțit în secțiuni, fiecare dintre acestea începând cu un anumit cuvânt cheie Cuvintele cheie nu trebuie să fie în majuscule așa cum le-am tastat, deși acesta este stilul preferat Cuvintele cheie încep toate cu un punct în prima coloană Observați că Secțiunea PARAMETER este inclusă pentru fiecare parametru oferit de funcție și Cuvântul cheie PARAMETER este urmat de numele parametrului EXEMPLU de secțiuni nu sunt numerotate, dar după cum veți vedea într-un moment, Power Shell le va numerota secvenţial pentru noi Suntem mari credincioși în documentarea Scripturilor, iar acest ajutor bazat pe comentarii servește la documentarea acestui script destul de bine Spre deosebire de comentariile de cod, ajutorul bazat pe comentarii nu este doar pentru cineva care citește scenariul! Funcționează și pentru cineva care utilizează instrumentul nostru, deoarece atunci când solicită ajutor, primește un afișaj de ajutor PowerShell cu aspect standard: NUME Get-Systemlnfo REZUMAT Preia informații despre versiunea cheie a sistemului și modelul de la unul la zece computere SINTAXĂ Get-Systemlnfo [-ComputerName] [[-ErrorLog] ] [- LogErrors] [ ] DESCRIERE Get-Systemlnfo utilizează Windows Management Instrumentation (WMI) pentru a prelua informații de pe unul sau mai multe computere Specificați computerele după nume sau după adresa IP PARAMETRI -ComputerName Unul sau mai multe nume de computer sau adrese IP, până la maximum true true true (ByValue) true (ByValue)Necesar? Poziţie? Valoare implicită Acceptați introducerea canalului? Acceptați caractere wildcard? fals -ErrorLog Când este utilizat cu -LogErrors, specifică calea fișierului și numele în care vor fi scrise numele computerelor eșuate Implicit, C:\Retry txt Necesar? fals Poziţie? Valoarea implicită c:\retry txt Acceptați introducerea canalului? fals Acceptați caractere wildcard? fals -LogErrors [ ] Specificați acest comutator pentru a crea un fișier jurnal text al computerelor care nu au putut fi interogate Necesar? fals Poziţie? numit Valoarea implicită False Acceptați introducerea canalului? fals Acceptați caractere wildcard? fals Acest cmdlet acceptă parametrii comuni: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer și OutVariable Pentru mai multe informații, consultați about CommonParameters (http://до microsoft corn/fwlink/ ?LinkID= ) INTRARI IEȘIRI EXEMPLUL C:\PS>Get-Content names txt | Get-Systemlnfo EXEMPLUL C:\PS>Get-SystemInfo -ComputerName SERVERI,SERVER Acum hai, teii-ne ca nu e misto! Exemplele noastre sunt toate defalcate și numerotate, ajutorul parametrului este formatat și chiar a preluat capacitatea parametrului nostru -ComputerName de a accepta intrarea din conducta ByValue! Acesta este, în cuvintele unui prieten de-al nostru pasionat de PowerShell, $ GREAT! Sistemul de ajutor a inclus chiar și ajutorul nostru pentru a se potrivi corect pe ecran și a adăugat micul prompt C: \PS> la exemplele noastre ! Ne pare rău, știm că țâșnim, dar aceasta este doar o caracteristică incredibil de îngrijită Sugestia noastră este să documentați fiecare dintre funcțiile dvs în acest fel, așa că sunt documentate atât pentru alți scriptori, cât și pentru cei care vor folosi tiiem Veți observa că unele secțiuni ale afișajului de ajutor, cum ar fi INPUT și OUTPUT, sunt goale Vedeți dacă puteți citi about comment based help și aflați cum să obțineți ca secțiunile să conțină informații Dacă sunteți mulțumit să vă puneți ajutorul bazat pe comentarii acolo unde am făcut-o, în partea de sus a funcției, dar în interiorul funcției, atunci puteți sări peste această bară laterală De asemenea, este legal să puneți ajutorul bazat pe comentarii chiar înaintea cuvântului cheie al funcției sau „chiar deasupra funcției” Cu toate acestea, pentru prima funcție din fișierul script, asigurați-vă că nu există mai mult de o linie goală între sfârșitul blocului de ajutor bazat pe comentarii și cuvântul cheie al funcției De asemenea, trebuie să existe cel puțin două linii goale între începutul scriptului și prima linie a ajutorului bazat pe comentarii În caz contrar, ajutorul va fi interpretat ca fiind pentru script, mai degrabă decât pentru funcție De asemenea, este legal să puneți ajutorul bazat pe comentarii la sfârșitul funcției, după tot codul funcției, dar înainte de paranteza de închidere a funcției} Credem că este un loc prostesc, pentru că forțează un alt scriptor să fie nevoit să deruleze până la sfârșitul unei funcții pentru a-și da seama ce ar trebui să facă Aceste reguli sunt exact motivul pentru care am pus ajutorul bazat pe comentarii acolo unde am făcut-o: este mai ușor, așa cum am menționat, să nu încurcă lucrurile așa! Preferința noastră sinceră este să folosim ajutorul bazat pe comentarii, dar asta pentru că vorbim doar engleză Singurul dezavantaj al ajutorului bazat pe comentarii este că nu acceptă ajutor multilingv Puteți introduce ajutorul bazat pe comentarii în engleză sau germană sau în orice altă limbă, dar trebuie să alegeți o singură limbă Utilizarea ajutorului bazat pe XML, pe de altă parte, vă permite să oferiți ajutor în mai multe limbi PowerShell alege automat limba pe baza propriei configurații Windows Acesta este modul în care comenzile native ale PowerShell le oferă ajutorul Urăm să facem asta, dar sincer, ajutorul bazat pe XML nu este ceva pe care îl veți folosi împreună cu un script Îl veți folosi în principal doar împreună cu un modul, care este doar o modalitate de a împacheta un script și mai multe fișiere suport, cum ar fi ajutorul bazat pe XML Nu vom ajunge la module până la capitolul , dar acum vom vorbi despre ajutor bazat pe XML Faptul este că majoritatea oamenilor (alți furnizori importanți de software, cum ar fi Microsoft) nu îl vor folosi, pentru că este mult mai complicat decât ajutorul bazat pe comentarii Sistemul de ajutor nativ al PowerShell folosește un format XML numit MAML, care este un pic un urs pentru a lucra și nu este în general foarte bine documentat În plus, acest ajutor este conținut într-un fișier extern, care vă ajută să vă mențineți funcțiile un pic mai scurte și mai lizibile prin mutarea ajutorului din acele comentarii uneori lungi Există câteva moduri de a face lucrul cu MAML puțin mai ușor: Utilizați Microsoft InfoPath, împreună cu un șablon InfoPadi pentru a crea un fișier de ajutor din scriptul dvs Veți găsi detalii și veți muri șablonul într-o postare de blog la Rețineți că nu puteți utiliza fișierele diat create de InfoPadi; trebuie să-i faceți o ajustare minoră pentru ca PowerShell să utilizeze corect fișierul matriță Acea postare pe blog explică ce trebuie să faci Descarca , care este un editor de ajutor cmdlet Acest instrument vă permite să creați și să lipiți fragmente din ajutorul dvs (rezumat, descriere și așa mai departe) și produce un fișier MAML gata de utilizat We diink diis este puțin mai ușor de folosit, dar este un proces manual destul de greoi Fiecare fișier XML conține ajutor pentru o singură limbă Trebuie să creați o structură de foldere adecvată în care să plasați fișierele Să presupunem că ați creat ajutor în limba engleză din SUA și ajutor în germană, toate pentru un modul numit Test psml (dacă ar fi să salvați fișierul nostru Test psl existent ca test psml, cu structura de foldere pe care urmează să o arătăm) tu, ar deveni magic un „modul de script”) Structura folderului de fișiere de ajutor trebuie să înceapă în același folder în care se află modulul de script Iată structura folderului: \Users\ \[My ]Documente \WindowsPowerShell \Modulele noastre au fost redenumite \Test Test psl test psml În engleză Test-help xml eu germană Test-help xml , în timp ce ajutorul în limba germană se află sub — acele două nume de foldere reflectă codurile de cultură interne pe care le folosește Windows pentru a identifica o limbă (sucii ca en sau de) și a acesteia variante regionale (sucii ca SUA sau, pentru engleza britanică, Marea Britanie) Puteți găsi o listă completă a codurilor culturale și limbile corespunzătoare la Observați că am specificat și un subiect despre întregul modul, care este doar un fișier text simplu Fișierul respectiv trebuie să aibă numele de fișier despre txt, unde este numele exact al modulului dvs - Testați în exemplul acesta De asemenea, am furnizat un fișier XML în fiecare limbă, care conține ajutor pentru funcțiile individuale Aceste fișiere XML sunt create folosind instrumentul PowerShell Help Editor (sau Info Path, dacă preferați) Puteți adăuga oricâte limbi doriți, cu condiția ca fiecare să fie inclusă într-un folder cu numele de cultură adecvat Un lucru pe care ar trebui să-l știți este că mulți utilizatori Internaționali PowerShell folosesc de fapt o versiune de Windows în engleză SUA, așa că limba lor implicită de ajutor este en-US Unii oameni de la Microsoft ne spun, deși compania oferă ajutor PowerShell în mai mult de o duzină de limbi, cele din SUA sunt cele mai des folosite Se pare că au existat erori în unele dintre fișierele care nu sunt în limba engleză care au rămas nedetectate luni de zile, deoarece oamenii nu folosesc acele fișiere Așadar, înainte de a vă scufunda în munca de traducere a fișierelor de ajutor în alte limbi decât engleza SUA, puteți verifica persoanele care vor folosi acest ajutor pentru a afla ce limbă (limbi) doresc Ajutorul bazat pe XML necesită cu siguranță ceva mai mult efort Merită dacă aveți (sau doriți să scrieți) ajutor extins, tiiat face ca ajutorul bazat pe comentarii să fie greu de utilizat sau dacă doriți să oferiți ajutor în mai multe limbi pentru un anumit script Bine, Get-Systemlnfo-ul nostru are un parametru -ErrorLog pentru câteva capitole acum și recent am adăugat -LogErrors pe deasupra tiiat Este timpul să nu mai amânăm sarcina de a face efectiv ceva, așa că tratarea erorilor va fi subiectul următorului nostru capitol Aceste laboratoare se vor baza pe ceea ce ați creat deja, aplicând concepte noi din acest capitol Adăugați ajutor bazat pe comentarii la funcția dumneavoastră avansată din Laboratorul A în capitolul Includeți cel puțin un rezumat, descriere și ajutor pentru parametrul -ComputerName Testează-ți ajutorul adăugând ajutor la sfârșitul scriptului Adăugați ajutor bazat pe comentarii la funcția dumneavoastră avansată din Lab Â în capitolul Includeți cel puțin un rezumat, descriere și ajutor pentru parametrul -ComputerName Testează-ți ajutorul adăugând ajutor la sfârșitul scriptului Adăugați ajutor bazat pe comentarii la funcția dumneavoastră avansată din Lab G în capitolul Includeți cel puțin un rezumat, descriere și ajutor pentru parametrul -ComputerName Testați-vă ajutorul adăugând ajutor la sfârșitul scriptului Folosind scriptul din lista următoare, adăugați ajutor bazat pe comentarii funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True,ValueFromPipeline=$True)] [ValidateNotNullOrEmpty()] [șir[]]$ComputerName ) PROCES { foreach ($computer în $computerName) { Write-Verbose „Obținerea datelor WMI de la $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $cs = Get-WmiObject -class Win ComputerSystem -computerName $computer $props = @{'ComputerName'=$computer; „LastBootTime”= ($os ConvertToDateTime($os LastBootupTime)); 'OSVersion'=$os version; Manufacturer'=$cs manufacturer; Model'=$cs model } $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } } Includeți cel puțin un rezumat, descriere și ajutor pentru parametrul -ComputerName Testează-ți ajutorul adăugând ajutor la sfârșitul scriptului Laboratoarele A, B și C pentru capitolele până la se bazează pe ceea ce sa realizat în capitolele anterioare Dacă nu ați găsit un laborator dintr-un capitol anterior, vă rugăm să faceți acest lucru Apoi verificați-vă rezultatele cu soluții eșantion pe MoreLunches com înainte de a continua să muriți următorul laborator în secvența matrițelor Funcția Get-Systemlnfo pe care am scris-o mai devreme a fost concepută de la început pentru a înregistra numele computerelor la care nu a reușit să le ajungă În acest capitol, vom face ca acest lucru să se întâmple, printr-un set de tehnici cunoscute în mod colectiv sub numele de tratare a erorilor De fiecare dată când o comandă PowerShell – fie că este un cmdlet nativ sau o funcție pe care o scrieți – întâmpină o eroare care nu se încheie, îi cere PowerShell ce trebuie să facă PowerShell analizează o variabilă încorporată, $ErrorActionPreference, pentru a vedea ce ar trebui să facă Înainte de a ne aprofunda în asta, să vorbim despre eroarea care nu este determinantă Este orice eroare care prezintă o problemă, dar una din care comanda se poate recupera și continua „Hei, acest computer a fost inaccesibil, dar dacă vrei, pot continua să încerc cu următorul computer din listă ” Aceasta este diferită de o eroare de terminare, ceea ce înseamnă că fiecare se va opri complet Deci, ce face $ErrorActionPreference? Poate fi setat la una dintre cele patru valori: Continuați—Acesta este implicit și spune: „Hei, dacă puteți continua, mergeți, dar afișați un mesaj de eroare pentru a mă anunța ce s-a întâmplat” Arată ca tiiis: PS C:\> $ErrorActionPreference = „Continuați” PS C:\> Get-WmiObject -class Win BIOS -ComputerName NOTONLINE, gazdă locală Get-WmiObject : Serverul RPC este indisponibil (Excepție de la HRESULT: X BA) La linia:l char:l + Get-WmiObject -class Win BIOS -ComputerName NOTONLINE,localhost + + Categorynfo : InvalidOperation: (:) [Get-WmiObject], COMExc ep ti on + FullyQualifiedErrorld: GetWMICOMException,Microsoft PowerShell Commands Get WmiObj ectCommand SMBIOSBIOSVersiune: Producator : Parallels Software International Inc Nume : BIOS implicit de sistem Număr de serie : Parallels-D A C АВ E AF C D FC DC Versiune : PRLS - SilentlyContinue—Acesta este setarea pe care ați dori să o aibă copiii dvs : „Continuați, nu vorbiți despre asta, nu afișați niciun mesaj de eroare – doar taci și continuă cu asta ” Arata cam asa: PS C:\> $ErrorActionPreference = 'SilentlyContinue' PS C:\> Get-WmiObject -class Win BIOS -ComputerName NOTONLINE, gazdă locală SMBIOSBIOSVersiune: Producator : Parallels Software International Inc Nume : BIOS implicit de sistem Număr de serie : Parallels-D A C АВ E AF C D FC DC Versiune : PRLS - Stop—Acest lucru transformă eroarea care nu se încheie într-o excepție finală, ceea ce înseamnă că comanda se oprește În mod implicit, acesta va afișa și un mesaj de eroare Iată ce se întâmplă: PS C:\> $ErrorActionPreference = „Oprire” PS C:\> Get-WmiObject -class Win BIOS -ComputerName NOTONLINE, gazdă locală Get-WmiObject : Serverul RPC este indisponibil (Excepție de la HRESULT: X BA) La linia:l char:l + Get-WmiObject -class Win BIOS -ComputerName NOTONLINE,localhost + + Categorynfo : InvalidOperation: (:) [Get-WmiObject], COMExc ep ti on + FullyQualifiedErrorld: GetWMICOMException,Microsoft PowerShell Commands Get WmiObj ectCommand Întrebați: „Întreabă-mă ce să fac” Literal, cu un prompt Acesta nu este aproape niciodată răspunsul corect, dar uneori poate fi util în situații de depanare Arata cam asa: PS C:\> $ErrorActionPreference = „Întrebare” PS C:\> Get-WmiObject -Class Win BIOS -ComputerName NOTONLINE, gazdă locală A confirma Serverul RPC este indisponibil (Excepție de la HRESULT: x BA) [Y] Da [A] Da tuturor [H] Comanda oprire [S] Suspendare [?] Ajutor (implicit este „Y”): Acum, să fim clari despre ceva: nu ar trebui să modificați $ErrorActionPreference în majoritatea cazurilor Unul dintre lucrurile care ne deranjează cel mai mult este să obținem un script de la cineva și să vedem $ErrorActionPreference= 'SilentlyContinue' chiar în partea de sus Ce încearcă, exact, să ascundă? Sigur, poate că vreo comandă provoacă o eroare și se simt confortabil doar să ascundă acea eroare, dar abordarea lor ascunde fiecare eroare pe care scriptul o poate produce! S-ar putea să fie informații utile și ascunderea acesteia s-ar putea simți mai bine (fără text roșu urât pe ecran!), dar nu vă ajută să funcționeze scriptul Necesarul lui este o modalitate de a trimite o comandă specifică, dacă doriți ca aceasta să aibă un comportament mai mare decât cel implicit atunci când apare o eroare Și poți face exact asta Este greu de realizat, dar fiecare comandă – chiar și cele pe care le scrii singur – acceptă un set de parametri comuni Veți vedea listat în ajutorul de sintaxă pentru fiecare comandă, iar dacă rulați ajutor despre common parameters, puteți vedea o listă cu toate Singurul lucru care ne preocupă acum este -ErrorAction, care poate fi prescurtat ca -EA Parametrul acceptă aceleași patru valori ca $ErrorActionPref erence: Continue, SilentlyContinue, Stop și Inquire Trucul este că, spre deosebire de $ErrorActionPref erence, -ErrorAction afectează doar această singură comandă Puteți suprima erorile doar pentru o singură comandă pe care o experiențați să le provoace, lăsând în același timp oricine altcineva să poată ridica orice erori neașteptate care să apară Dar SilentlyContinue nu va fi obiectivul nostru În schimb, vom folosi mult Stop Acest lucru se datorează faptului că excepția de terminare produsă de Stop este o oarecare pe care o putem prinde, permițându-ne să gestionăm singuri eroarea mai mult decât să primim mesajul de eroare implicit Parametrul comun anodier este -ErrorVariable sau -EV Aceasta vă permite să specificați un nume de variabilă (rețineți că numele variabilei nu include semnul dolar) și orice eroare produsă de comanda die va fi stocată în acea variabilă, astfel încât să o puteți examina și să luați orice acțiune doriți Iată cum funcționează: PS C:\> Get-WmiObject -Class Win BIOS -ComputerName NOTONLINE -EV err -EA SilentlyContinue PS C:\> $err Get-WmiObject : Serverul RPC este indisponibil (Excepție de la HRESULT: x BA) La linia:l char:l + Get-WmiObject -Class Win BIOS -ComputerName NOTONLINE -EV err -EA SilentlyCont + Categorynfo : InvalidOperation: (:) [Get-WmiObject], COMExcepție + FullyQualifiedErrorld: GetWMICOMException,Microsoft PowerShell Commands Get WmiObj ectCommand Trebuie să fii foarte atent cu -ErrorVariable De exemplu, luați în considerare acest lucru: PS C:\> $x = 'fred' PS C:\> Gwmi Win BIOS -ErrorVariable $x Eroarea nu este în $x Eroarea este în $f roșu Vedeți, i-am spus lui -ErrorVariable să acceseze conținutul ofx - asta înseamnă die $ în fața unui nume de variabilă Deci -ErrorVariable a căutat în interiorul x, a găsit Fred și a creat o variabilă $fred Tiiere nu este nicio problemă cu utilizarea tehnicii tiiis dacă asta ai vrut, dar dacă ai intenționat ca eroarea să intre în $x, poți vedea cât de confuz ar fi diis Dacă diat a fost intenția noastră, dien die comanda ar fi trebuit să arate ca diis: PS C:\> Gwmi Win BIOS -ErrorVariable x Fiți atenți când furnizați numele variabilei diat Vom acoperi pe scurt această construcție de gestionare a erorilor, deoarece s-ar putea să o întâlniți în scriptul cuiva pe care l-ați găsit pe internet Dacă nu credeți că asta se va întâmpla vreodată, treceți peste secțiunea următoare, pentru că nu credem că veți scrie comenzi noi folosind acest construct Numele constructului este Trap În esență, funcționează ca tiiis: Când o comandă provoacă o eroare de terminare (pe care o puteți declanșa folosind -ErrorAction Stop), PowerShell scanează înapoi în domeniul curent pentru a vedea dacă există o construcție Trap Citiți cu atenție: nu va scana înainte în domeniu, ceea ce înseamnă că trebuie să vă definiți capcana înainte de a crede că eroarea va apărea Ca rezultat, capcanele tind să apară în partea de sus a fișierului script Când PowerShell detectează o capcană, rulează orice cod se află în interior Scopul joacă un rol important cu Trap și poate deveni foarte complex, ceea ce reprezintă o mare parte din motivul pentru care oamenii nu o mai folosesc atât de mult De exemplu, să presupunem că vă aflați într-o funcție și apare o eroare PowerShell va căuta în interiorul funcției o capcană Dacă nu primește unul, PowerShell iese din funcție, urcă cu un nivel (să spunem că funcția este în interiorul unui script, deci suntem acum în domeniul de aplicare al scriptului) și caută o capcană acolo Dacă găsește unul, îl va executa La sfârșitul capcanei, puteți executa una dintre cele două comenzi: Break sau Continue Break iese din domeniul curent, trecând eroarea originală în domeniul părinte Este ca și cum ai spune: „Nu m-am putut descurca cu această eroare, așa că ți-o predau și sunt înțeles ” Continue va relua execuția în același domeniu, la comanda următoare celei care a provocat eroarea Confuz? Da, și noi Acest lucru este cu adevărat greu de urmărit Ceea ce este mai rău este că Trap în sine are propriul său domeniu de aplicare - deci este dificil să modificați variabilele sau orice modificare în Trap, pentru că făcând acest lucru doar (în mod implicit) se creează noi elemente în interiorul Trap în sine, fără a afecta domeniul de aplicare al capcanei Nu vom explora mai departe această construcție Dacă trebuie să aflați mai multe despre el pentru a traduce un script vechi pe care l-ați găsit, rulați ajutor despre capcană în shell; vă recomandăm să rămâneți cu tehnici mai noi în orice instrumente noi pe care le scrieți Introdus în PowerShell v , acesta este modalitatea reală de a gestiona erorile Toți copiii cool o fac, pentru că este mai ușor și seamănă mai mult cu gestionarea erorilor găsită în limbajele de programare tradiționale Se numește Încearcă Captură În cele din urmă, și o vom introduce în funcția noastră Get-Systemlnfo pentru a vă arăta cum funcționează Verificați această listă funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('hostname')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” PROCES { Scriere-verboză „Început blocul PROCES” pentru fiecare ($computer în $numecomputer) { Scriere-verboză „Interogare $computer” Încercați { $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -erroraction Stop } Captură { if ($LogErrors) { $computer | Out-File $ErrorLog -Adăugați } } $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } SFÂRŞIT { } } Get-Systemlnfo -computername NOTONLINE Deci ce am făcut? Am adăugat -ErrorAction Stop la comanda despre care ne așteptăm să provoace o eroare, Get-WmiObject Am înconjurat comanda care cauzează erori într-o construcție Try{} Am creat o construcție Catch{}, care va fi executată dacă apare o excepție de terminare oriunde în construcția Try{} Observați că verificăm variabila $LogErrors, care este parametrul nostru de comutare -LogErrors, pentru a vedea dacă ar trebui să înregistrăm erori Dacă suntem, adăugăm numele computerului eșuat la orice fișier specificat în $ErrorLog Nu am inclus un construct Finally {}, deoarece este opțional Dar dacă am fi ales să facem acest lucru, conținutul său s-ar fi executat indiferent dacă a apărut sau nu o eroare în construcția Try {} Aveți opțiunea de a include mai multe constructe Catch{} Dacă faceți acest lucru, fiecare identifică una sau mai multe excepții pentru acel bloc Catch{} Puteți defini o gestionare diferită a erorilor pentru diferite excepții Citiți despre try catch f inally în shell pentru exemple de mai multe blocuri Catch{} Nu am terminat cu gestionarea erorilor În acest moment, funcția noastră verifică numai erorile la prima comandă Get-WmiObj ect Dacă asta eșuează, nu ar trebui să sărim peste cele rămase? La urma urmei, sunt la fel de probabil să eșueze, nu? Uită-te la următoarea listă funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scriere-verboză „Început blocul PROCES” pentru fiecare ($computer în $numecomputer) { Scriere-verboză „Interogare $computer” Încercați { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -eroare Stop } Captură { $totul ok = $fals if ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } } SFÂRŞIT { } } Get-Systemlnfo -computername NOTONLINE -logerori Am pus lucrurile noi cu caractere aldine în lista Practic, înainte de a rula prima comandă Get-WmiObject, am creat o nouă variabilă, $everything ok, și am stabilit-o la $True Suntem baieti optimisti Dacă comanda diat provoacă o eroare, $everything ok este setat la $False, indiferent dacă vom înregistra eroarea sau nu Apoi, executăm restul funcției die numai dacă $everything ok este încă $True Dovada este în execuție, așa că asigurați-vă că puteți rula scriptul tiiis (asigurați-vă că includeți parametrul -LogErrors, așa cum am făcut în ultima linie a scriptului) cu un nume de computer prost și ca numele computerului să apară în tiie fișier jurnal O problemă pe care o avem cu gestionarea erorilor este că nu mai afișăm un mesaj de eroare util oricui execută scriptul nostru S-ar putea, de exemplu, să nu-și amintească sau să-și dea seama unde este fișierul jurnal de erori! Deci, să facem o ultimă modificare, în următoarea listă, afișează o anunțare (care este mai puțin gravă pentru o eroare) utilizatorului funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scriere-verboză „Început blocul PROCES” pentru fiecare ($computer în $numecomputer) { Scriere-verboză „Interogare $computer” Încercați { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -erroraction Stop } Captură { $totul ok = $fals Avertisment de scriere „$computer a eșuat” if ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați avertisment de scriere „Logged to $ErrorLog” } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } } SFÂRŞIT { } } Get-Systemlnfo -ComputerName NOTONLINE -LogErrors Doar câteva apeluri către Wr i te - Warning fac rezultatul scriptului nostru mult mai util: PS C:\> C:\test ps! AVERTISMENT: NOTONLINE a eșuat AVERTISMENT: Conectat la c:\retry txt Obiectul excepție este transmis blocului Catch ca $ , astfel încât să puteți limita o mulțime de informații din acesta Un lucru pe care Jeff îl include adesea în blocurile sale Catch este o linie ca aceasta: Write-Warning $ Exception Message, astfel încât utilizatorul să poată vedea mesajul de eroare fără excepție Dacă utilizați die common -errorvariable, puteți trece și diat Dar variabila die este o excepție, așa că ați putea face diis, presupunând o variabilă errorr de err: Write-Warning $err message Începem să facem aceste instrumente suficient de complexe pentru a exista neapărat erori și trebuie să vă arătăm cum să le eliminați cât mai eficient posibil Așadar, în următorul capitol, ne vom lua o pauză rapidă de la construirea Get-Systemlnfo (și funcțiile de laborator) și ne vom concentra pe depanare Veți continua cu funcțiile pe care le-ați construit în ultimele câteva capitole Următorul pas este să începeți să încorporați o anumită gestionare a erorilor folosind Try Captură In cele din urma Dacă nu ați făcut acest lucru, acordați-vă câteva minute pentru a citi conținutul de ajutor din Încercați Captură In cele din urma Pentru orice modificări pe care le faceți, nu uitați să actualizați ajutorul bazat pe comentarii Folosind Laboratorul A din capitolul , adăugați un parametru -ErrorLog la funcția dumneavoastră avansată , care acceptă un nume de fișier pentru un jurnal de erori și este implicit C:\Errors txt Când funcția este rulată cu acest parametru, numele computerelor eșuate ar trebui să fie atașate la fișierul jurnal de erori Apoi, dacă prima interogare WMI eșuează, funcția nu ar trebui să scoată nimic pentru acel computer și nu ar trebui să încerce o a doua sau a treia interogare WMI Scrieți o eroare în conducta care conține fiecare nume de computer eșuat Testați toate acestea adăugând această linie -ComputerName localhost, NOTONLINE -verbose la sfârșitul scriptului O parte din ieșire ar trebui să arate cam așa: VERBOSE: Pornirea Get-Computerdata VERBOSE: Obținerea datelor de la localhost VERBOSE: Win Computersystem VERBOSE: Win Bios VERBOSE: Win peratingSystem innotek GmbH CLIENT VirtualBox NA innotek GmbH CLIENT VirtualBox NA Grup de lucru Producător Nume computer Versiune Număr de serie Model Parola administratorului ServicePackMaj sau Versiune VERBOSE: Obținerea datelor de la notonline VERBOSE: Win Computersystem Get-Computerdata : Nu a reușit obținerea informațiilor de sistem de la notonline Serverul RPC este indisponibil (Excepție de la HRESULT: x BA) La S:\Toolmaking\ChlO-LabA ps!: char: + 'localhostnotonlinelocalhost' | Get-Computerdata -logerrors -verbose + + Categorynfo : NotSpecified: (:) [Eroare de scriere], WriteErrorException + FullyQualifiedErrorld: Microsoft PowerShell Commands WriteErrorException,Get-Comp uterData VERBOSE: Obținerea datelor de la localhost Folosind Lab Â din capitolul , adăugați un parametru -ErrorLog la funcția dumneavoastră avansată, care acceptă un nume de fișier pentru un jurnal de erori și este implicit C:\Errors txt Când funcția este rulată cu acest parametru, numele computerelor eșuate ar trebui să fie atașate la fișierul jurnal de erori Testați toate acestea adăugând această linie -ComputerName localhost, NOTONLINE -verbose la sfârșitul scriptului O parte din ieșire ar trebui să arate cam așa: VERBOSE: Pornirea Get-Volumelnfo VERBOSE: Obținerea datelor de la localhost Spatiu liber Conduce Numele calculatorului mărimea , \\?\Volum{ d f CLIENTUL , , C:\Temp\ CLIENTUL , C:\ CLIENTUL , D:\ CLIENTUL VERBOSE: Obținerea datelor de la NotOnline Get-Volumelnfo : Nu s-au putut obține informații despre volum de la NotOnline Serverul RPC este indisponibil (Excepție de la HRESULT: x BA) La S:\Toolmaking\ChlO-LabB psl: char: + 'localhostNotOnline' | Get-Volumelnfo -Verbose -logerrors + + Categorynfo : NotSpecified: (:) [Eroare de scriere], WriteErrorException + FullyQualifiedErrorld: Microsoft PowerShell Commands WriteErrorException,Get-Volu melnfo VERBOSE: Erori de înregistrare în C:\Errors txt VERBOSE: Ending Get-Volumelnfo Folosind Lab C din capitolul , adăugați un parametru de comutare -LogErrors la funcția dumneavoastră avansată De asemenea, adăugați un parametru -ErrorFile, care acceptă un nume de fișier pentru un jurnal de erori și este implicit C:\Errors txt Când funcția este rulată cu parametrul -LogErrors, numele computerelor eșuate ar trebui să fie atașate la fișierul jurnal de erori De asemenea, dacă se utilizează LogErrors, fișierul jurnal ar trebui șters la începutul funcției dacă există, astfel încât de fiecare dată comanda să pornească cu un fișier jurnal nou Testați toate acestea adăugând această linie - Сотри terName localhost, NOTONLINE -verbose -logerrors la sfârșitul scriptului O parte din ieșire ar trebui să arate cam așa: VERBOSE: Serviciul de procesare wuauserv VERBOSE: Obținerea procesului pentru wuauserv Nume computer: CLIENT Număr fire: Nume proces: svchost exe Nume : wuauserv VMS : PeakPageFile: Nume afișat: Windows Update VERBOSE: Obținerea de servicii de la NOTOnline Get-Servicelnfo : Nu s-au putut obține date de serviciu de la NOTOnline Serverul RPC este indisponibil (Excepție de la HRESULT: x BA) La S:\Toolmaking\ChlO-LabC psl: char: + "localhost","NOTOnline","localhost" | Get-Servicelnfo -logerrors -verbose + + Categorynfo : NotSpecified: (:) [Eroare de scriere], WriteErrorException + FullyQualifiedErrorld: Microsoft PowerShell Commands WriteErrorException,Get-Serv icelnfo VERBOSE: Erori de înregistrare în C:\Errors txt VERBOSE: Obținerea de servicii de la localhost VERBOSE: Serviciul de procesare AudioEndpointBuilder VERBOSE: Procesul de obținere pentru AudioEndpointBuilder Utilizați codul din lista următoare ca punct de plecare Funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [ValidateNotNullOrEmpty()] [șir[]]$ComputerName ) PROCES { foreach ($computer în $computerName) { WWrite-Verbose „Obținerea datelor WMI de la $computer” $os = Get-WmiObject -class Win OperatingSystem -computerName $computer $cs = Get-WmiObject -class Win ComputerSystem -computerName $computer $props = @{'ComputerName'=$computer; „LastBootTime”= ($os ConvertToDateTime($os LastBootupTime)); 'OSVersion'=$os version; Manufacturer'=$cs manufacturer; Model'=$cs model } $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } } Adăugați un comutator -LogErrors la această funcție avansată Când funcția este rulată cu acest comutator, numele computerelor eșuate ar trebui să fie înregistrate în C:\Errors txt Acest fișier ar trebui să fie șters la începutul funcției de fiecare dată când este rulat, astfel încât să înceapă proaspăt de fiecare dată Dacă prima interogare WMI eșuează, funcția ar trebui să scoată notii pentru computerul respectiv și nu ar trebui să încerce o a doua interogare WMI Scrieți o eroare în conducta care conține fiecare nume de computer eșuat Testați-vă scriptul adăugând această linie la sfârșitul scriptului Get-Systemlnfo -computername localhost,NOTONLINE,localhost -logerrors O parte din ieșire ar trebui să arate cam așa: Model : VirtualBox ComputerName: gazdă locală Producator: innotek GmbH LastBootTime: : : Versiune OS: Get-Systemlnfo: NOTONLINE a eșuat La S:\Toolmaking\ChlO-Standalone psl: char:l + Get-Systemlnfo -computername localhost,NOTONLINE,localhost -logerrors + + Categorynfo : NotSpecified: (:) [Eroare de scriere], WriteErrorException + FullyQualifiedErrorld: Microsoft PowerShell Commands WriteErrorException, Get-Syst emlnfo Model : VirtualBox ComputerName : localhost Producator : innotek GmbH LastBootTime: : : Versiune OS: Laboratoarele A, B și C pentru capitolele până la se bazează pe ceea ce sa realizat în capitolele anterioare Dacă nu ați găsit un laborator dintr-un capitol anterior, vă rugăm să faceți acest lucru Apoi verificați rezultatele cu soluții eșantion pe MoreLunches com înainte de a trece la următorul laborator din secvență Depanarea poate fi una dintre cele mai frustrante părți ale fabricării de unelte și credem că este adesea din cauza faptului că oamenii nu au o abordare consecventă și metodică a depanării Asta vă vom oferi în acest capitol Vom face chiar și o promisiune: dacă urmați recomandările noastre, veți constata că depanarea va fi intim mai puțin frustrantă Vă vom prezenta chiar și câteva exemple de depanare din viața reală pentru a vă ajuta să conduceți acasă punctul mort Considerăm că întregul univers al erorilor software, cel puțin universul PowerShell, se reduce în esență la unul dintre cele două tipuri: greșeli de scriere și erori de logică Greșelile de scriere sunt destul de simple: sunt ceea ce se întâmplă atunci când scrieți ceva greșit Poate este un nume de comandă Poate ai introdus greșit un nume de variabilă Poate ai uitat un ghilimele de închidere sau o paranteză Oricare ar fi cauza, greșelile de scriere sunt relativ ușor de prevenit (vom oferi câteva sfaturi pe scurt) și de rezolvat, cel puțin în comparație cu vărul mai sinistru, erorile de logică Când un script are o eroare de logică, se poate rula fără să afișeze mesaje de eroare sau orice erori pe care le produce par să nu aibă legătură sau vagi În alt mod, scriptul nu face ceea ce vrei tu să facă Am constatat că, în final, erorile de logică se reduc la o singură cauză directă: tu (sau oricine a scris scenariul) a făcut o presupunere greșită Poate ați presupus că o comandă va scoate „True” când de fapt scoate un întreg obiect plin de date; poate ați presupus că o variabilă conținea o valoare șir, când de fapt conținea un număr Indiferent de cauza, presupunerile proaste se află la baza aproape oricărei erori de logică Cea mai mare parte a acestui capitol se va concentra pe modul de validare și corectare a acestor ipoteze și așteptări Greșelile de scriere sunt reparabile Sunt chiar ușor de observat din față, mai ales dacă formatați cu atenție Scripturile Da, ți-am spus încă de la începutul acestei cărți că chestia cu materii va continua să iasă la suprafață și chiar o vom pune acum Totuși, nu vrem să facem din acesta un capitol mare despre greșeli de scriere, așa că haideți să rămânem cu această scurtă listă de sfaturi: Faceți cunoștință cu software-ul dvs de editare de scripturi, fie că este vorba de PowerShell ISE sau de altceva Obișnuiți-vă cu culorile, indicatorii de eroare, opțiunile de afișare și așa mai departe La jumătatea timpului, greșelile de tipar, cum ar fi ghilimele neînchise și parantezele, se dezvăluie în culori nenormale și alte artefacte, făcându-le destul de ușor de prins dacă ești atent Formatați-vă scripturile cu grijă Codul de indentare cu paranteze {} și paranteze () și așezați parantezele de închidere (sau paranteze) la același nivel de indentare ca și linia care a deschis construcția Citiți mesajele de eroare Sincer, PowerShell face tot posibilul să vă spună de ce este supărat Luați în considerare comanda și eroarea rezultată, în cazul în care PowerShell clarifică faptul că nu înțelege numele parametrului scris greșit (l-am scris cu caractere aldine pentru dvs ) și chiar vă spune poziția exactă a caracterului ( ) unde există problema Chiar și, în modul ei bazat pe caracter, a subliniat partea care a avut o problemă cu (și în aldinea noastră)! PS C:\> Get-Service -nume computer localhost -Nume s* Get-Service : nu poate fi găsit un parametru care să se potrivească cu numele parametrului „nume calculator” La linia:l char: + Get-Service -nume computer localhost -Nume s* + + Categorynfo : InvalidArgument: (:) [Get-Service], ParameterBinding Excepție + FullyQualifiedErrorld: NamedParameterNotFound,Microsoft PowerShell Commands GetServiceCommand Știm, de fiecare dată când ecranul se umple cu text roșu, ne încurcăm într-o minge și ne întoarcem la ora de engleză de la liceu, unde cerneala roșie era un lucru rău, rău Dar relaxează-te, ia o scurtă respirație și citește ce încearcă să-ți spună PowerShell Greșeală de scriere rezolvată După cum am menționat mai devreme, ipotezele și așteptările se află în centrul erorilor și erorilor mai complicate pe care le veți găsi Înainte de a începe depanarea, trebuie să aveți o așteptare pentru ceea ce va face fiecare linie a scriptului și trebuie să fiți capabil să validați aceste așteptări Când găsești locul în care așteptările tale diferă de realitate, ți-ai găsit bug-ul Dar nu puteți depana fără să vă așezați mai întâi și să vă gândiți la ce ar trebui să facă scenariul – sau cel puțin la ce credeți că ar trebui să facă Acesta este exact locul în care majoritatea oamenilor greșesc Ideea de a sta jos și a studia cu atenție un scenariu, rând cu rând, pare ineficientă, plictisitoare și frustrantă Așa că vor intra imediat și vor începe să facă schimbări Astfel, din experiența noastră, duce la nebunie I-am urmărit ore în șir pe studenți făcând un scenariu stricat, făcând dureros schimbări după schimbare care nu ajută Da, poate părea ineficient să încerci să citești un scenariu și să-ți documentezi așteptările (deși atunci când vei deveni mai experimentat, vei face multe în cap și va merge mai repede) Dar modul nostru de depanare este mult mai eficient decât abordarea „încearcă lucruri și vezi ce se întâmplă” Modul nostru are ca rezultat o mai bună înțelegere a scenariului și un timp de remediere mai rapid, încercând chestii aleatoriu Să începem cu un exemplu simplu, diat nici măcar nu folosește un script, dar radier folosește o singură linie de comandă simplă: PS C:\> Get-Cimlnstance -clasa Win LogicalDisk -filtru ”drivetype=’fixed’” | Selectați -Property DeviceID,Size | Sortare -Proprietate FreeSpace Get-Cimlnstance: INVALID QUERY La linia: char:l + Get-Cimlnstance -clasa Win LogicalDisk + + Categorynfo : InvalidArgument: (:) [Get-Cimlnstance], CimException + FullyQualifiedErrorld: MiClientApiError InvalidQuery, Microsoft Management I nfrastructure CimCmdlets GetCimlnstanceCommand Uite, un mesaj de eroare Ne spune (am îngroșat partea la care ne uităm) că problema este cu comanda Get-Cimlnstance Aveam o așteptare cu privire la ceva care nu era în regulă Să examinăm doar acea parte a comenzii noastre De fapt, la naiba cu asta - hai să rulăm doar porțiunea aia Am tastat acest lucru în PowerShell ISE, așa că putem evidenția doar porțiunea care reprezintă prima comandă, facem clic dreapta pe ea și selectam Run Selection (sau apăsați F ) pentru a rula doar acea comandă Observați, așa cum se arată în figura , că am avut grijă să nu evidențiem caracterul pipe după prima comandă Acest lucru asigură că PowerShell rulează doar prima comandă și că shell-ul nu se așteaptă la nimic după aceea Adm : ni stra ud r: Windows PowerShe SL File Edil Vew Tools Debog Add-oos Hei o ' • □ dacă ■ c j Unjdtdlpll* | LiiLpii | X Evidențiați o porțiune de cod și apăsați F pentru a rula doar acea porțiune Iată rezultatul nostru: PS C:\> Get-Cimlnstance -class Win LogicalDisk -filtru „drivetype=’fixed’” Get-Cimlnstance: INVALID QUERY La linia:l char:l + Get-Cimlnstance -clasa Win LogicalDisk + + Categorynfo : InvalidArgument: (:) [Get-Cimlnstance], CimException + FullyQualifiedErrorld: MiClientApiError InvalidQuery,Microsoft Management I nfrastructure CimCmdlets GetCimlnstanceCommand Aceeași eroare - deci problema este cu siguranță cu această comandă Abordarea noastră standard în acest caz este să ne retragem puțin Aceasta înseamnă că vom elimina puțin din comandă, dacă este posibil, pentru a reduce complexitatea și a vedea dacă putem găsi ce facem greșit Uite, există doar doi parametri pentru această comandă - clar am introdus unul greșit Deci, să scăpăm de unul, dacă este posibil: PS C:\> Get-Cimlnstance ; -clasa Win LogicalDisk Spatiu liber Identificatorul dispozitivului DriveType VolumeName mărimea A: C: D: HB CCPA X F Ah A funcționat (deși am trunchiat puțin rezultatul pentru a se potrivi pe pagina din această carte) Problema a fost parametrul nostru -Filter Privind rezultatul comenzii reușite, putem vedea că proprietatea DriveType conține numere — , sau în cazul nostru Nu este ceea ce ne așteptam – ne-am gândit că va fi ceva de genul „remediat”, care este ceea ce era în interogarea noastră Ipoteza corectata Să reparăm comanda și să încercăm din nou: PS C:\> Get-Cimlnstance -clasa Win LogicalDisk -filtru „drivetype= ” | Selectați -Property DeviceID,Size | Sortare -Proprietate FreeSpace Dimensiunea ID dispozitiv C: Ei bine, așa e mai bine Deși poate că nu Computerul nostru are o singură unitate fixă (tip de unitate ), așa că nu putem fi siguri că comanda noastră Sortare funcționează Să eliminăm filtrul de tip de unitate, astfel încât să obținem mai multe unități în ieșire, astfel încât să ne putem asigura că Sortarea funcționează Este rău să presupunem că Sortarea funcționează atunci când aveți un singur obiect în ieșire! Get-Cimlnstance -clasa Win LogicalDisk | Selectați -Property DeviceID,Size | Sortare -Proprietate FreeSpace Dimensiunea ID dispozitiv D: C: A: Așteaptă, sortăm după FreeSpace, dar asta nici măcar nu este afișat în rezultat Deci nu putem teii dacă funcționează De fapt, poate că am făcut o prostie aici Comanda noastră Select alege doar proprietățile DeviceID și Size—ieșirea sa probabil nici măcar nu are un FreeSpace pentru a sorta Să testăm acest lucru dând puțin înapoi și eliminând comanda Sort și apoi vedem ce produce Select: Get-Cimlnstance -clasa Win LogicalDisk | Selectați -Property DeviceID,Size | Obțineți-membru TypeName: Selected Microsoft Management Infrastructure Cimlnstance Name Name MemberType Definition MemberType Definition Equals Metoda bool Equals(System Object obj) Metoda GetHashCode int GetHashCode() GetType ToString DeviceID Size GetType ToString DeviceID Sizemetodă GetType() metodă ToString() NoteProperty System String DeviceID=A: NoteProperty Size=null Așa am crezut noi După cum arată Get-Member, comanda noastră Sort încearcă să sorteze pe o proprietate care, în acel moment în conductă, nu există Greșeală stupidă din partea noastră, dar renunțarea la o comandă și examinarea rezultatului cu Get-Member ne-a ajutat să confirmăm suspiciunea Nu este iritant faptul că PowerShell nu a aruncat o eroare când am încercat să sortăm ceva care nu exista la momentul respectiv? Dar asta face Acum știm că poate ar trebui să mutăm comanda noastră Sort la mai devreme în pipeline, sau pur și simplu să o eliminăm în întregime, sau să punem Select să includă proprietatea sortare în rezultatul său Oricare dintre acestea ar rezolva problema Ideea acestui exemplu este că ipotezele sunt cele care duc la erori Verificarea și validarea datelor, adesea rulând doar fragmente din scriptul dvs , renunțând puțin și așa mai departe vă poate ajuta să vă corectați presupunerile și să remediați eroarea Să lucrăm printr-un exemplu rapid de dezvoltare a așteptărilor: Aruncă o privire la lista Nu am făcut nicio modificare la acest script, pe care ni l-a furnizat unul dintre colegii noștri, în afară de a elimina numele de identificare și informațiile proprii Vă încurajăm să urmați acest proces de documentare a așteptărilor Rețineți că nu poziționăm acest script ca fiind unul care urmează cele mai bune practici — departe de asta — dar este un exemplu real $date = import-csv c:\data csv $totalqty = $totalsold = $totalbought = foreach ($line în $date) { dacă ($line transaction -eq „cumpără”) { tranzacție de cumpărare (am vândut) $totalqty -= $line qty $totalsold = $line total } else { tranzacție de vânzare (am cumpărat) $totalqty += $line qty $totalbought = $line total } „totalqty,totalbought, totalsold,totalamt” | out-file c:\summary csv „$totalqty,$totalbought, $totalsold,$($totalbought-$totalsold)” | out-file c:\summary csv -append Acest script este destinat procesării unui fișier CSV, care este scos de o altă aplicație Următoarea listă arată un eșantion de date ale fișierului CSV „nume, tranzacție, cantitate, sumă, total” "c tgannon,cumpără, , , , , " „gshields,sell, , , ” "tevans,sell, , , " Nu vom rula scriptul În primul rând, formatarea este atroce Trebuie să rezolvăm asta mai întâi - nici o cale de ocolire Următoarea listă este scriptul revizuit și imediat putem vedea o problemă Gan l-ai observat? $date = import-csv c:\data csv $totalqty = $totalsold = $totalbought = foreach ($line în $date) { dacă ($line transaction -eq „cumpărare”) { tranzacție de cumpărare (am vândut) $totalqty -= $line qty $totalsold = $line total } altfel { tranzacție de vânzare (noi am cumpărat) $totalqty += $line qty $totalbought = $line total } „totalqty,totalbought,totalsold,totalamt” | out-file c:\summary csv „$totalqty,$totalbought,$totalsold,$($totalbought-$totalsold)” | out-file c:\summary csv -append Dacă citiți cu atenție, veți observa că paranteza de închidere a construcției ForEach lipsește Următoarea listă arată scriptul remediat - acest tip de eroare este mult mai ușor de observat atunci când formatați corect scriptul $date = import-csv c:\data csv $totalqty = $totalsold = $totalbought = foreach ($linie în $date) { dacă ($line transaction -eq „cumpără”) { tranzacție de cumpărare (am vândut) $totalqty -= $line qty $totalsold = $line total } altfel { tranzacție de vânzare (noi am cumpărat) $totalqty += $line qty $totalbought = $line total } } „totalqty,totalbought,totalsold,totalamt” | out-file c:\summary csv „$totalqty,$totalbought,$totalsold,$($totalbought-$totalsold)” | out-file c:\summary csv -append Nu rulați încă acest script Știm că este cu probleme – acesta este un fel de ideea acestui exercițiu Vom alerga într-o secundă să vedem ce face! Acum să începem să ne documentăm așteptările Nici măcar nu vom rula scenariul – este vorba despre așteptările noastre, bazate pe ceea ce vedem $date = import-csv c:\data csv $totalqty = $totalsold = $totalbought = Aceste primele patru rânduri par să importe un fișier CSV (v-am dat o mostră despre cum arată acesta) Ne așteptăm ca fiecare linie din CSV să devină un obiect și fiecare coloană din CSV să devină o proprietate a acelui obiect Folosind datele noastre eșantion, ar trebui să existe trei obiecte cu cinci proprietăți fiecare Restul de trei linii par să inițialeze unele variabile, setându-le valorile la zero - o idee grozavă, având în vedere regulile de aplicare ale PowerShell foreach ($linie în $date) { } Construcția ForEach ar trebui să enumere prin aceste trei obiecte, astfel încât variabila $line să conțină câte un obiect dacă ($line transaction -eq „cumpără”) { tranzacție de cumpărare (am vândut) $totalqty -= $line qty $totalsold = $line total } altfel { tranzacție de vânzare (noi am cumpărat) $totalqty += $line qty $totalbought = $line total } Construcția If verifică proprietatea Tranzacție a fiecărui obiect (adică coloana Tranzacție din fișierul CSV) Dacă este „cumpără”, există un set de acțiuni, iar dacă nu este, există un alt set Acest lucru ridică un mic semnal roșu pentru noi: dacă CSV este garantat că va conta doar „cumpără” și „vând” așa cum face eșantionul nostru, atunci doar folosirea unui bloc Else este în regulă În mod normal, dacă ne așteptăm la valori specifice, cum ar fi „cumpărare” și „vinde”, am vedea mai degrabă un bloc Elseif care testează în mod explicit „vânzarea” sau dacă au existat mai multe valori, poate o declarație Switch Așa cum este, dacă fișierul CSV conține ceva aberant precum „swap” în coloana Tranzacție, va fi tratat ca o „vânzare”, ceea ce ar putea cauza probleme Vom lăsa acest alunecare pentru moment În afară de asta, codul pare simplu: incrementăm unele variabile în funcție de conținutul coloanelor Cantitate și Total ale fișierului CSV Ultimele două rânduri ale scenariului sunt „totalqty,totalbought,totalsold,totalamt” | out-file c:\summary csv „$totalqty,$totalbought,$totalsold,$($totalbought-$totalsold)” | out-file c:\summary csv -append Aceasta scoate două linii într-un nou fișier CSV, prima linie acționând ca antete de coloană, iar a doua linie folosind acele variabile pentru a produce o singură linie de date pentru fișierul CSV Să testăm această teorie rulând scriptul: PS C:\> C:\debug ps! PS C:\> gc \summary csv totalqty,totalbought,totalsold,totalamt ,, , Așa că am rulat scriptul (pe care l-am salvat ca C:\debug psl) și apoi am afișat conținutul ci siimmary csv Toate zerourile și o coloană goală Minunat Ei bine, știam că scenariul a fost stricat – să învățăm cum să-l reparăm O tehnică excelentă pentru a trata erorile logice este să adăugați cod de urmărire la script-ul dvs Acest lucru vă permite să afișați câteva detalii interne despre ceea ce vede și se confruntă scriptul dvs , permițându-vă să validați aceste ipoteze (presupunând că ați făcut unele - iar dacă nu ați făcut-o, nu sunteți pregătit să depanați) Majoritatea limbajelor de programare oferă o modalitate de a adăuga cod de urmărire; PowerShell face acest lucru într-un mod care înseamnă că nu trebuie să vă întoarceți mai târziu și să eliminați sau să comentați comenzile codului de urmărire Este super comod! Avem tendința de a adăuga codul de urmărire, care este implementat prin utilizarea Write-Debug, pe măsură ce scriem un nou script Tindem să presupunem că vom da greșelii, iar adăugarea codului de depanare de la început face depanarea mai rapidă Și pentru a fi perfect sincer, am început să ne bazăm pe codul de urmărire pentru a acționa ca comentarii inline pentru Scripturile noastre, mai mult decât comentariile reale Următoarea listă arată scriptul nostru cu codul de urmărire adăugat [CmdletBinding()] param() $date = import-csv c:\data csv Write-Debug „Date CSV importate” $totalqty = $totalsold = О $totalbought = О foreach ($linie în $date) { dacă ($line transaction -eq „cumpără”) { Scriere-Depanare „Tranzacție CUMPĂRARE TERMINATĂ (am vândut)” $totalqty -= $line qty $totalsold = $line total } altfel { $totalqty += $line qty $totalbought = $line total Scriere-Depanare „Tranzacție de VÂNZARE TERMINATĂ (am cumpărat)” } } Scriere-Depanare „OUTPUT: $totalqty,$totalbought,$totalsold, $($totalbought-$totalsold)" „totalqty,totalbought,totalsold,totalamt” | out-file c:\summary csv „$totalqty,$totalbought,$totalsold,$($totalbought-$totalsold)” | out-file c:\summary csv -append Dacă introduceți un script ca acesta, asigurați-vă că îl salvați înainte de a încerca să îl rulați Unele lucruri, cum ar fi atributul [CmdletBinding () ], vor funcționa numai dacă scriptul dumneavoastră este rulat de pe un fișier de pe disc Câteva note despre ceea ce am făcut: Pentru a face acest lucru cu adevărat util, am adăugat [CmdletBinding () ] și un bloc Param () necompletat în partea de sus a scriptului Aceste două elemente trebuie să meargă împreună — nu puteți avea [CmdletBinding () ] fără un Param() Vă vom arăta într-o secundă de ce [CmdletBinding () ] este atât de minunat aici Am adăugat un Write-Debug după fiecare decizie sau operație majoră luată de script, dându-ne șansa de a urma logica scriptului Deoarece rezultatul final al acestui fișier este un fișier CSV (care încalcă regula noastră de a împărți instrumentele în intrare, funcțional sau ieșire, dar hei, este ceea ce ni s-a dat să depanăm), am adăugat o diat Write-Debug care ne permite să previzualăm ieșirea Să rulăm din nou scriptul De data aceasta, vom adăuga comutatorul -Debug (care este activat de [CmdletBinding () ] ) pentru a face vizibilă rezultatul Write-Debug: Vom rula diis în consola PowerShell normală, care ne place ceva mai mult pentru depanare Mesajele sale – pe care le veți vedea în următoarea ieșire – sunt solicitări text, în timp ce ISE utilizează dialoguri pop-up care ne distrag puțin atenția PS C:\> \debug ps! - Depanare DEBUG: date CSV importate A confirma Continuați cu această operațiune? [Y] Da [A] Da tuturor [H] Comanda oprire [S] Suspendare [?] Ajutor (implicit este „Y”): Când PowerShell a lovit primul Write-Debug, și-a afișat mesajul și a întrerupt scriptul De aici, avem câteva alegeri Vom selecta S pentru „Suspend” A confirma Continuați cu această operațiune? [Y] Da [A] Da tuturor [H] Comanda oprire [S] Suspendare [?] Ajutor (implicit este „Y”):s PS C:\>> $date nume, tranzacție, cantitate, sumă, total ctgannon,cumpără, , , , , gshields,sell, , , tevans,sell, , , Observați că promptul PowerShell s-a schimbat în >> în loc de >, indicând că suntem în modul de depanare Profităm de această ocazie pentru a vedea ce a intrat de fapt în variabila $date – și nu a fost ceea ce ne așteptam Amintiți-vă, am spus că ne așteptăm ca $data să conțină trei obiecte a câte cinci proprietăți fiecare, dar pare să fie doar o bunăii de text Dacă ați făcut ceva pentru a modifica promptul dvs PowerShell (numeroase programe de completare terță parte fac acest lucru), este posibil să nu vedeți aceeași ieșire pe care o vedem noi Vă recomandăm să rulați PowerShell fără niciun program de completare pentru a restabili promptul original de depanare, dacă este necesar Încă în modul de depanare, vom trimite $data către Get-Member pentru a vedea ce este în variabila tiiat: PS C:\>> $date | gm TypeName: System Management Autoration PSCustomObject Nume MemberType Definiție Egal Metodă bool Egal (System Objec GetHashCode Metodă int GetHashCode() GetType Metodă tastați GetType() ToString Metodă șir ToString() nume, tranzacție, cantitate, sumă, total NoteProperty System String name,trans Ei bine, nu este un șir – este un obiect cu o proprietate numită nume, tranzacție, cantitate, sumă, total Ciudat și nu ceea ce ne așteptam Aceasta este o proprietate, nu cinci Nu ne putem aștepta ca restul scriptului să funcționeze, motiv pentru care am primit o ieșire ciudată prima dată când l-am rulat Examinând fișierul CSV, problema pare să fie ghilimele Între ghilimele, formatul de fișier CSV ignoră virgulele, ceea ce înseamnă că întregul fișier este luat ca o singură proprietate Să reparăm asta, cu eșantionul revizuit afișat aici nume,tranzacție,cantitate,suma,total ctgannon,cumpărare, , , , , gshields,vinde, , , , , tevans,vinde, , , , , Ar fi legal să includeți fiecare câmp între ghilimele — de exemplu, „nume”, „tranzacție”, „cantitate”, „suma”, „total” — dar, deoarece niciuna dintre valorile noastre nu conține virgule, putem elimina și ghilimelele în întregime , care este mai rapid Toate acestea sunt o problemă potențială, deoarece se presupune că aceste date sunt scoase de o altă aplicație Prin urmare, această aplicație are o eroare, deoarece scrie fișiere CSV ilegale Vom lăsa totuși dezvoltatorul acelei aplicații să se ocupe de problemele lor și să continuăm depanarea scriptului nostru Suntem încă la promptul de depanare Să ieșim, să oprim scriptul și să-l rulăm din nou PS C:\>> ieșire A confirma Continuați cu această operațiune? [Y] Da [A] Da tuturor [H] Comanda oprire [S] Suspendare [?] Ajutor (implicit este „Y”):h Write-Debug : Execuția comenzii s-a oprit deoarece utilizatorul a selectat opțiunea Oprire La C:\debug psl: char:l + Scriere-Depanare „Date CSV importate” + + Categorynfo : OperationStopped: (:) [Write-Debug], Parent ContainsErrorRecordException + FullyQualifiedErrorld: ActionPreferenceStop, Microsoft PowerShell C ommands WriteDebugCommand PS C:\> \debug psl -Debug DEBUG: date CSV importate A confirma Continuați cu această operațiune? [Y] Da [A] Da tuturor [H] Comanda oprire [S] Suspendare [?] Ajutor (implicit este „Y”):s PS C:\>> $date Nume ctgannon tranzacţie Cumpără cantitate Cantitate total Nume gscuturi tranzacţie vinde cantitate Cantitate total , Nume tevans tranzacţie vinde cantitate Cantitate total Ah, mult mai mult la ceea ce ne așteptam: trei obiecte a câte cinci proprietăți fiecare Excelent Să permitem scriptului să continue: PS C:\>> exit Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: ENDED BUY transaction (we ; Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: ENDED SELL transaction (we Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: ENDED SELL transaction (we Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: OUTPUT: , , , Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"): PS C:\>> exit Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: ENDED BUY transaction (we ; Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: ENDED SELL transaction (we Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: ENDED SELL transaction (we Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"):y DEBUG: OUTPUT: , , , Confirm Continue with this operation? [Y] Yes [A] Yes to All [H] Halt (default is "Y"): Command [S] Suspend [ ?] Help iold) Command [S] Suspend [ ?] Help bought) Command [S] Suspend [ ?] Help bought) Command ) [S] Suspend [ ?] Help Command [S] Suspend [ ?] Help Command [S] Suspend [ ?] Help iold) Command [S] Suspend [ ?] Help bought) Command [S] Suspend [ ?] Help bought) Command ) [S] Suspend [ ?] Help Command [S] Suspend [ ?] Help A recunoscut în mod corespunzător fiecare dintre cele trei tranzacții, dar avem o mică problemă cu linia de ieșire propusă După calculele noastre, coloanele și nu ar trebui să fie și , ci mai degrabă și Deci avem o altă problemă Vă spun ce: Să omorâm din nou scriptul și să depanăm restul utilizând o altă tehnică: A confirma Continuați cu această operațiune? [Y] Da [A] Da tuturor [H] Comanda oprire [S] Suspendare [?] Ajutor (implicit este „Y”):h Write-Debug : Execuția comenzii s-a oprit deoarece utilizatorul a selectat opțiunea Oprire La C:\debug psl: char:l + Scriere-Depanare „IEȘIRE: $totalqty,$totalbought,$totalsold,$($totalbought-$totalsold + Categorynfo : OperationStopped: (:) [Write-Debug], Parent ContainsErrorRecordException + FullyQualifiedErrorld: ActionPreferenceStop, Microsoft PowerShell C ommands WriteDebugCommand Din punct de vedere tehnic, Write-Debug acționează ca un fel de punct de întrerupere permanent, inserat manual în scriptul tău Când shell-ul atinge Write-Debug, vă întrerupe scriptul și vă permite să investigați lucrurile PowerShell acceptă, de asemenea, o formă mai dinamică de punct de întrerupere, numită PSBreakpoint Creați un PSBreakpoint rulând Set-PSBreakpoint Folosind parametrii acelei comenzi, puteți spune PowerShell cu ce script merge punctul de întrerupere (se bazează pe calea și numele fișierului, deci punctul de întrerupere va funcționa doar atâta timp cât scriptul rămâne în același loc) și pe ce doriți să declanșeze punctul de întrerupere Alegerile dvs includ următoarele: Oprirea pe o anumită linie sau poziție de linie/caracter, care este similar cu lipirea unui Write-Debug în script Oprirea când este executată o anumită comandă Oprirea când o anumită variabilă este citită, scrisă sau oricare Din punct de vedere tehnic, nu trebuie să legați altceva decât un punct de întrerupere linie/caracter la un fișier script Celelalte tipuri de puncte de întrerupere pot funcționa și la nivel global în cadrul shell-ului Rețineți că punctele de întrerupere sunt dinamice: închideți-vă carcasa și ele dispar De fapt, nu faci nimic scriptului tău, ci mai degrabă îi ceri lui PowerShell să-și amintească ce să faci De asemenea, puteți seta puncte de întrerupere bazate pe linii în ISE: Doar treceți la linia unde doriți un punct de întrerupere și apăsați F Deoarece în acest moment avem probleme cu variabilele noastre $totalbought și $totalsold, vom seta puncte de întrerupere pentru acestea: PS C:\> Set-PSBreakpoint -Script C:\debug ps! -Variabila totalbought, totalso Id -Mode ReadWrite ID Script Line Command Variable Action debug psl totalbought debug psl totalsold Bum, două noi puncte de întrerupere Să rulăm scriptul, omițând parametrul -Debug, astfel încât instrucțiunile noastre Write-Debug să nu intre: PS C:\> \debug psl Se intră în modul de depanare Folosiți h sau ? pentru ajutor Atingeți punctul de întrerupere variabilă pe „C:\debug psl:$totalsold” (acces Citire Scriere) La C:\debug psl: char: + $totalsold = + [DBG] : PS C:\>> Primul punct de întrerupere! Aici vă dați seama că ar fi util să aveți o imprimare a scriptului dvs , inclusiv numerele de rând Ne-am oprit pe linia , care setează $totalsold la zero Vom rula Exit pentru a continua să rulăm scriptul: Atingeți punctul de întrerupere variabilă pe „C:\debug psl:$totalbought” (acces Citire Scriere) La C:\debug psl: char: + $totalbought = [DBG]: PS C:\>> ieșire Atingeți punctul de întrerupere variabilă pe „C:\debug psl:$totalsold” (acces Citire Scriere) La C:\debug psl: char: + $totalsold = $line total + [DBG]: PS C:\>> Bine, linia este locul unde modificăm mai întâi $totalsold Să vedem cât dolar ine totalul conține: [DBG]: PS C:\>> $line total [DBG]: PS C:\>> ieșire Atingeți punctul de întrerupere variabilă pe „C:\debug psl:$totalbought” (acces Citire Scriere) La C:\debug psl: char: + $totalbought = $line total + este ceea ce ne așteptam, așa că am rulat din nou Exit Acum am modificat $totalbought, așa că scriptul s-a întrerupt din nou Să vedem ce este în $ ine total: [DBG]: PS C:\>> $line total , [DBG]: PS C:\>> ieșire Atingeți punctul de întrerupere variabilă pe „C:\debug psl:$totalbought” (acces Citire Scriere) La C:\debug psl: char: + $totalbought = $line total + Bine, din nou, este pe drumul cel bun Am continuat, așa că să ne uităm acum la $line total și $totalbought din nou: [DBG]: PS C:\>: > $line total [DBG]: PS C:\>: > $totalbought [DBG]: PS C:\>: Asteapta asteapta asteapta $totalbought ar trebui să conțină + , care este , dar conține doar Înapoi la cod: $totalbought = $line total Și acolo este problema Nu adăugăm $line total la ceea ce este în $totalbought; setăm $totalbought la orice se află în $line total Deci vechea valoare este ștearsă Același lucru se întâmplă și în Ștotalsold, chiar deasupra lui în scenariu Să facem câteva remedieri, așa cum se arată în lista următoare [CmdletBinding()] param() $data = import-csv c:\data csv Write-Debug „Date CSV importate” $totalqty = О $totalsold = О $totalbought = О foreach ($line în $date) { dacă ($line transaction -eq „cumpără”) { Scriere-Depanare „Tranzacție CUMPĂRARE TERMINATĂ (am vândut)” $totalqty -= $line qty $totalsold += $line total } altfel { $totalqty += $line qty $totalbought += $line total Scriere-Depanare „Tranzacție de VÂNZARE TERMINATĂ (am cumpărat)” } } Scriere-Depanare „OUTPUT: $totalqty,$totalbought,$totalsold,$($totalbought- $totalsold)” „totalqty,totalbought,totalsold,totalamt” | out-file c:\summary csv „$totalqty,$totalbought,$totalsold,$($totalbought-$totalsold)” | out-file c:\summary csv -append Acum să ștergem punctele de întrerupere și să o rulăm din nou: PS C:\> Get-PSBreakpoint | Eliminați-PSBreakpoint PS C:\> \debug psl PS C:\> gc \summary csv totalqty,totalbought,totalsold,totalamt , , , PS C:\> Huza! A mers! Depanare finalizată! Puteți vedea că toate acestea ar fi fost imposibil dacă nu am fi dezvoltat niște așteptări: ce credeam că vor conține variabilele, ce credeam că va fi rezultatul (recunoaștem că am scos un calculator pentru a adăuga și , dar nu există motiv pentru a fi stânjenit de diat, există?), și așa mai departe Am folosit instrumente pentru a compara aceste așteptări cu ceea ce s-a întâmplat cu adevărat – și de fiecare dată când am găsit o diferență, am știut să ne scufundăm înapoi în codul pentru a găsi problema Acesta este un fapt simplu despre depanare: fără așteptări, ești în frig Aveți așteptări, iar instrumentele din PowerShell vă vor permite să validați și să găsiți erorile În capitolul următor, vom reveni la exemplul nostru de rulare Get-Systemlnfo, unde îl avem producând rezultate excelente, dar nu rezultate atractive Comenzi precum Get-Service produc implicit un tabel foarte frumos formatat și am dori ca comanda noastră să facă la fel În capitolul următor vom lucra la tiiat Suntem siguri că veți avea o mulțime de practică pentru depanarea propriilor Scripturi Dar dorim să întărim unele dintre conceptele din acest capitol și să vă obișnuim să urmați o procedură Nu încercați niciodată să depanați un script pur și simplu privindu-l, în speranța că eroarea vă va apărea S-ar putea, dar mai mult ca sigur s-ar putea să nu fie singurul Urmați instrucțiunile noastre pentru a identifica erori Remediați câte un lucru Dacă nu rezolvă problema, schimbați-o înapoi și repetați procesul Funcțiile enumerate aici sunt stricate și cu erori Am numerotat fiecare rând în scop de referință; numerele nu fac parte din funcția reală Cum le-ai depana? Revizuiți-le în soluții de lucru Amintiți-vă, va trebui să punctați sursa scriptului de fiecare dată când faceți o modificare Vă recomandăm să testați în consola PowerShell obișnuită Funcția din lista următoare ar trebui să afișeze unele proprietăți ale serviciilor care rulează, sortate după contul de serviciu Funcția Get-Servicelnfo { [cmdletbinding()] Param([șir]$Computername) $services=Get-WmiObject -Class Win Services -filter "state='Running" -computernam $computernam Write-Host „Găsit ($services count) pe $computername” -Foreground Green $servicii | sortare -Property startname,name Selectare -property startname,name,startmode,computername } Funcția din listarea este puțin mai implicată Este conceput pentru a obține intrări recente din jurnalul de evenimente pentru un jurnal specificat pe un computer specificat Evenimentele sunt sortate după sursa evenimentului și adăugate la un fișier jurnal Numele fișierului se bazează pe dată, numele computerului și sursa evenimentului La sfârșit, funcția afișează o listă de director cu jurnalele Sugestie: Culegeți mai întâi formatarea Funcție Export-EventLogSource { [cmdletbinding()] Param ( [Parameter(Position= , Mandatory=$True,Helpmessage="Introduceți un nume de computer",ValueFromPipeline=$True) ] [șir]$Computername, [Parameter(Position=l, Mandatory=$True,Helpmessage="Introduceți un nume clasic de jurnal de evenimente, cum ar fi System")] [șir]$Log, [int]$Newest= ) ÎNCEPE { Scriere-Verbose „Pornirea funcției sursă de evenimente de export” #formatul datei face distincție între majuscule și minuscule" $datestring=Get-Date -Format „aaaaMMzz” $logpath=Calea de alăturare -Calea „C:\Work” -ChildPath $datestring if (! (Calea-test -cale $logpath) { Scriere-verboză „Se creează $logpath” mkdir $logpath } Scrieți-verbose „Înregistrarea rezultatelor la $logpath” } Proces { Scrieți-verbose „Obținerea celor mai noi $noile $log intrări din jurnalul de evenimente de la $computername” Încerca { Scriere-gazdă $numecomputer Sup -Prim planColor Verde $logs=Get-EventLog -LogName $log -Cel mai nou $Newest -Computer $Computer ErrorAction Stop dacă ($jurnal) { Scriere-verboză „Sortarea intrărilor $($logs count)” $log | sortare Sursa | pentru fiecare { $logfile=Join-Path -Cale $logpath -ChildPath "$computername- $($ Source) txt" $ | Format-List TimeWritten,MachineName,EventID,EntryType,Message | Out-File -FilePath $logfile -append variabile tfclear pentru data viitoare Remove-Variable -Nume jurnalele, fișierul jurnal } else {Write-Warning „Nu s-au găsit evenimente înregistrate pentru $log pe $Computername} Prinde {Write-Warning $ Exception Message } } Sfârșit {dir $logpath Scrieți-verbose „Funcția sursă de evenimente de export finalizată” } } Puteți găsi versiuni depanate ale acestor funcții și un comentariu despre cum le puteți depana la Ne întoarcem la scenariul cu care am lăsat-o în capitolul , înainte de scurta noastră diversiune în lumea depanării Unul care nu ne-a plăcut la scriptul diat a fost rezultatul său Unii oameni ar fi tentați să pună comenzi direct în scriptul pentru a remedia diat, dar știm mai bine Rețineți: un instrument ar trebui să creeze intrare pentru instrumentul anodier, să facă ceva sau să formateze ieșirea din instrumentul anodier Instrumentul nostru face deja ceva, așa că nu îl putem lăsa să înceapă să încurce și ieșirea matriței cu formatare Widi În schimb, vom face ca PowerShell să facă asta pentru noi, creând o vizualizare personalizată PowerShell este livrat cu un număr de vizualizări, toate fiind conținute în fișiere format pslxml tiiatlive în folderul de instalare al PowerShell Puteți ajunge acolo rulând cd $pshome în shell și vom deschide DotNetTypes format pslxml în Notepad (sau ISE) pentru a-l vizualiza Aveți mare grijă să nu faceți nicio modificare în fișierele format pslxml din folderul de instalare PowerShell sau, dacă o faceți, asigurați-vă că nu salvați modificările respective Fișierele sunt semnate digital și chiar și un spațiu suplimentar sau returnarea căruciorului va rupe tiiem, făcându-i inutil pentru PowerShell Tiiere este o mulțime de lucruri în tiiere, dar să începem doar cu o vedere simplă de tabel: I Numele vizualizării Sistem globalizare Informații culinare System Globalization CuitureInfo Table column headers Table column headers LCID Nume DisplayName Iată ce am dori să observați: Vizualizarea este conținută în etichetele XML și Rețineți că toate etichetele XML țin cont de majuscule și minuscule, așa că este important să introduceți cu precizie Preferăm să creăm și să lipim o vizualizare existentă din DotNetTypes format pslxml și să o folosim ca punct de plecare, deoarece acest lucru ne ajută să evităm greșelile de scriere în XML Vederea are un nume propriu, care este de obicei doar numele tipului căruia se va aplica vizualizarea Numele nu contează prea mult - există câteva moduri în care shell-ul îl poate folosi, dar sunt extrem de rare de întâlnit Vizualizarea este selectată printr-un nume de tip specific, în acest caz, obiecte de tip System Globalization Culturelnfo Deci, atunci când PowerShell trebuie să afișeze acel tip de obiect, va folosi această vizualizare pentru a face acest lucru Aceasta este o vizualizare de tabel, spre deosebire de o vizualizare listă, largă sau personalizată Există trei anteturi de coloană - numărați-le cu atenție Ultimul este afișat de eticheta XML ; aceasta reprezintă o coloană în care nu furnizăm un antet, lățime sau aliniere de coloană personalizate Este ușor să ratezi antetul al treilea al coloanei, așa că asigură-te că îl vezi! XML-ul rămas definește conținutul celor trei coloane Veți observa că fiecare dintre acestea specifică numele proprietății obiectului care va fi afișat în coloană Deoarece anteturile coloanelor noastre nu au inclus nume alternative, numele proprietăților vor fi folosite în partea de sus a fiecărei coloane Acest formular de bază este utilizat pentru toate vizualizările Un singur fișier XML, așa cum veți vedea în DotNetTypes format pslxml dacă vă uitați în el, poate conține mai multe vizualizări, fiecare pentru un alt tip de obiect Deoarece vizualizările sunt declanșate de numele tipului obiectului pe care îl afișează, trebuie să ne asigurăm că obiectul de ieșire al scriptului nostru are un nume de tip unic Momentan nu: scriptul produce un tip generic de obiect numit PSObject Următoarea listă arată cum vom remedia acest lucru, cu o singură linie afișată cu caractere aldine funcția Get-Systemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) BEGIN { Write-Verbose „Jurnalul de erori va fi $ErrorLog” } PROCESS { Scrie-verbose „Beginning PROCESS block” foreach ($computer în $computername) { Scriere-verboză „Interogare $computer” Încerca { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -eroare Stop } Captură { $everything ok = $false Avertisment de scriere „$computer a eșuat” dacă ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați avertisment de scriere „Logged to $ErrorLog” } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-Verbose "Interogări WMI complete" $obj = Nou-Object -TypeName PSObject -Property $props $obj PSObj ect TypeNames Insert( , MOL Systemlnfo ) Scriere- Ieșire $obj } } } SFÂRŞIT { } } Get-Systemlnfo -ComputerName localhost | Obțineți-membru Acesta este motivul principal pentru care am stocat obiectul nostru de ieșire într-o variabilă, $obj, în primul rând - pentru că știam că îi vom adăuga un nume de tip personalizat Metoda Insert () ia două argumente Primul, unde am furnizat zero, spune metodei unde să insereze noul nume de tip Zero înseamnă pur și simplu „puneți acest nume de tip în prima poziție”, făcându-l numele de tip utilizabil pentru obiectul nostru Al doilea argument este un șir cu numele tipului însuși Am folosit un nume de tip din două părți: MOL (care înseamnă „Luna de prânz”) este primul și ne va ajuta să ne diferențiem numele tipului de celelalte deja în NET Framework Gândiți-vă la MOL ca la un fel de prefix care este unic pentru noi Ați dori să utilizați ceva unic pentru organizația dvs De exemplu, dacă ați lucrat pentru IBM, ați putea folosi IBM ca prefix Dacă ați lucrat pentru departamentul de cercetare și dezvoltare a IBM din Charlotte, ați putea folosi IBM Research Charlotte ca prima parte a numelui dvs de tip - din nou, doar pentru a vă asigura că numele complet al tipului este unic Systemlnfo reprezintă, pentru noi, tipul de informații pe care le conține acest obiect Rularea scriptului nostru și transmiterea rezultatelor către Get-Member (care se realizează prin ultima linie din scriptul matriței) dovedește că numele tipului a fost într-adevăr setat: PS C:\> C:\test ps! TypeName: MOL Systemlnfo Nume MemberType Definiție Equals Metoda bool Equals(System Object obj) Metoda GetHashCode int GetHashCode() GetType Tip de metodă GetType() ToString Metoda șir ToString() BlOSSerial NoteProperty System String BIOSSerial=Parallels- C ComputerName NoteProperty System String ComputerName=localhost Producător NoteProperty System String Manufacturer=Software Parallels Model NoteProperty System String Model=Platformă virtuală Parallels OSVersion NoteProperty System String SVersion= SPVersion NoteProperty System UIntl SPVersion= Cu numele tipului atribuit, acum putem începe să facem o vizualizare Înainte de a face acest lucru, vom face o modificare scriptului nostru: Pe ultima linie, vom elimina | Get-Member, astfel încât rularea scriptului să afișeze rezultatul normal, dorit al scriptului Chiar acum, iată cum arată: PS C:\> C:\test psl Producator: Parallels Software International Inc OS : BlOSSerial : Parallels-D A C АВ E AF C D FC DC ComputerName : localhost SPVersiune : Model : Platformă virtuală Parallels Asigurați-vă că puteți urmări până în acest punct și că scriptul dvs afișează această ieșire Nu vom mai face modificări scriptului în acest capitol, așa că dacă reușiți să ajungeți la acest punct, atunci ar trebui să fiți gata Vom începe cu următoarea listă, unde am furnizat shell-ul de bază pentru fișierul XML Am salvat-o ca C:\Testformat ps IxmL Vă sugerăm să salvați fișierele de vizualizare pe o cale scurtă, cum ar fi G:\ sau C:\Test sau altceva, în timp ce lucrați la fișier Veți tasta mult acea cale, așa că dacă o păstrați scurt, veți economisi timp și efort Rețineți că conținutul fișierului nostru arată deja practici bune de formatare XML: indentăm fiecare set imbricat de etichete și ne asigurăm că fiecare etichetă este închisă la nivelul corespunzător De exemplu, cea mai exterioară pereche de etichete este , și în aceasta vom plasa vizualizările noastre reale Vom începe prin a copia o vizualizare de tabel existentă din DotNetTypes format pslxmL Noul fișier este în lista următoare Systern Ref ection Assembly Systern Ref ection Assembly GAC Versiune GlobalAssemblyCache ImageRuntimeVersion Locație Am permis formatării noastre îngrijite să se încurce puțin pentru a lăsa acest lucru să se potrivească în paginile acestei cărți Ceea ce avem aici este un tabel cu trei coloane De fapt vrem cinci coloane: Numele calculatorului Producător, pe care îl vom afișa ca Producător în antetul coloanei și va limita la de caractere Model, pe care îl vom limita și la de caractere OSVersion SPVersion, pe care îl vom afișa ca SP în antetul coloanei Următoarea listă arată tabelul nostru modificat M L Systemlnfo MOL Systemlnfo Mfgr SP Mfgr SP Column I Column I Column Column Column Column ComputerName Producător Model OSVersion SPVersion Să acordăm o atenție deosebită anteturilor de coloană: Prima coloană este o etichetă , care în XML este numită etichetă singleton Asta înseamnă că nu vine în perechi Am folosit acest lucru pentru că am vrut (a) antetul coloanei să fie doar numele proprietății și (b) PowerShell pentru a calcula cea mai bună lățime a coloanei A doua coloană are atât un labei, cât și o lățime A treia coloană are o lățime, dar nu are etichetă, așa că numele proprietății va fi folosit ca antet de coloană A patra coloană este un alt singleton, ceea ce înseamnă că va folosi numele proprietății și o lățime cea mai potrivită A cincea coloană are un labei, dar nu are lățime, ceea ce înseamnă că PowerShell va calcula lățimea cea mai potrivită pentru noi Cu aceasta salvată ca G:\Test format pslxml, suntem gata să-l testăm Fișierele de vizualizare trebuie să fie încărcate în memorie în cadrul fiecărei noi sesiuni shell, ceea ce se realizează prin utilizarea Update-FormatData Vom specifica calea folosind parametrul -PrependPath; puteți citi ajutorul comenzii pentru a afla despre alte opțiuni PS C:\> Update-FormatData -PrependPath C:\test format pslxml Update-FormatData : Au existat erori la încărcarea fișierului de date cu format: C:\test format pslxml, Eroare la XPath /Configuration/ViewDefinitions/View[ ]/TableControl în fișier C:\test format pslxml: Numărul de elemente din antet = nu se potrivește cu numărul implicit de elemente de rând = C:\test format pslxml, Eroare la XPath /Configuration/ViewDefinitions/View[ ] în fișierul C:\test format pslxml: Lipsește nodul din TableControl, ListControl, WideControl, CustomControl La linia:l char:l + Update-FormatData -PrependPath C:\test format pslxml + + Categorynfo : InvalidOperation: (:) [Update-FormatData], RuntimeException + FullyQualifiedErrorld: TypesXmlUpdateException,Microsoft PowerShel Commands UpdateFormatDataCommand E în regulă – erorile apar uneori Am îndrăznit partea interesantă a erorii, care ne spune că am definit șase anteturi de coloană, dar numai cinci corespondențe de coloană Hopa, Lista arată fișierul revizuit; dacă reveniți la lista , puteți vedea că aveam un suplimentar la sfârșitul listei de antet de coloană (este pe linia din XML) Acele single-uri sunt greu de ratat – am lăsat-o intenționat pentru a vă arăta această eroare MOL Systemlnfo MOL Systemlnfo Mfgr SP ComputerName Producător Model OSVersion SPVersion Acum că am reparat fișierul, putem încerca să-l încărcăm din nou: PS C:\> Update-FormatData -PrependPath C:\test format pslxml Fără erori este o veste bună! În vl și v din PowerShell, trebuie să închideți complet shell-ul pentru a încerca să reîncărcați un fișier de vizualizare eșuat Acest lucru a fost corectat în v De asemenea, v este mai puțin sensibil la majuscule decât versiunile anterioare Pe linia a fișierului nostru XML, am scris o etichetă în loc de , dar PowerShell a acceptat-o oricum Acesta nu ar fi fost cazul în versiunile anterioare ale shell-ului XML-ul nostru a funcționat doar pentru că am scris și eticheta de închidere Dacă nu am fi potrivit litera dintre ele — dacă am fi tastat și , de exemplu, fișierul XML ar fi eșuat Dacă utilizați ISE pentru a edita aceste fișiere XML, verificarea de sintaxă va identifica aceste tipuri de erori, subliniindu-le cu o subliniere roșie ondulată Fiți atenți la acestea și lăsați-le să vă ajute să identificați erorile înainte ca acestea să devină o problemă! Scriptul nostru este încărcat în ISE, așa că vom intra în panoul său din consolă și vom importa fișierul de vizualizare (am testat fișierul de vizualizare în consola PowerShell normală, care este o aplicație separată; pentru a utiliza vizualizarea in cadrul ISE trebuie sa-l incarcam si acolo) Figura arată că fișierul a fost încărcat fără eroare Adm stra or W dows owerShe Sf Acum putem reveni la fila script-ului, apăsăm F pentru ao rula și vedem dacă noua noastră vizualizare a intrat în vigoare Figura prezintă rezultatele Perfect! Exact asta ne-am dorit Observați că, deoarece am constrâns coloanele Mfgr și Model la de caractere, PowerShell trunchiază conținutul cu puncte de suspensie ( ) E in regula; este ceea ce ne-am dorit Dacă nu ne-ar plăcea, am putea, evident, să modificăm die XML pentru a oferi o coloană mai largă sau pur și simplu să eliminăm în întregime directiva die widdi și să lăsăm PowerShell să calculeze lățimea cea mai potrivită pentru coloana Ca de obicei, încheiem acest capitol cu o problemă Mai exact, instrumentul nostru este inclus într-un script și, dacă cineva plănuiește să-l folosească, trebuie să-și amintească și să încarce manual fișierul XML de vizualizare personalizată Asta e inacceptabil De asemenea, trebuie să punem scriptul într-o formă ușor de distribuit, astfel încât oamenii să poată încărca instrumentele noastre în memorie și să le ruleze ca comenzi normale, mai degrabă decât să fie nevoie să codificați o linie pentru a rula funcția din partea de jos a scriptului Următorul capitol va rezolva ambele probleme: Vom transforma scriptul nostru într-un modul Pun pariu că poți ghici ce urmează Veți adăuga informații de tip și veți crea fișiere de format personalizate pentru funcțiile la care ați lucrat în ultimele câteva capitole Utilizați fișierele dotnettypes format pslxml și alte fișiere pslxml ca surse pentru aspectul eșantionului Gopy și inserați XML în noul fișier format Nu uitați că etichetele sunt sensibile la majuscule și minuscule Modificați funcția avansată din Laboratorul A din capitolul , astfel încât obiectul de ieșire să aibă numele de tip MOL ComputerSystemlnf o Apoi, creați o vizualizare personalizată într-un fișier numit G:\GustomViewA format pslxml Vizualizarea personalizată ar trebui să afișeze obiecte de tip MOL ComputerSystemlnfo într-un format de listă, afișând informațiile într-o listă, așa cum este indicat în proiectarea dvs pentru acest laborator Reveniți la capitolul pentru a verifica care ar trebui să fie numele de ieșire În partea de jos a fișierului script, adăugați aceste comenzi pentru a testa: Update-FormatData -prepend c:\CustomViewA format pslxml -ComputerName localhost Rezultatul final ar trebui să arate cam așa: CLIENT NA VirtualBox innotek GmbH CLIENT NA VirtualBox innotek GmbH Numele calculatorului Grup de lucru Parola administratorului Model Producător BIOSSerialNumber OSVersion SPVersion Rețineți că etichetele listei nu sunt exact aceleași cu numele proprietăților obiectului personalizat Modificați funcția dumneavoastră avansată Lab В din capitolul , astfel încât obiectul de ieșire să aibă numele de tip MOL Disklnfo Apoi, creați o vizualizare de tabel personalizată într-un fișier numit G:\Gustom-ViewB format pslxmL Vederea personalizată ar trebui să afișeze obiecte de tip MOL Disklnfo într-un format de tabel, afișând informațiile într-un tabel, așa cum este indicat în proiectarea dumneavoastră pentru acest laborator Consultați capitolul pentru o reîmprospătare Antetele de coloană pentru proprietățile FreeSpace și Size ar trebui să afișeze FreeSpace (GB) și, respectiv, Size (GB) În partea de jos a fișierului script, adăugați aceste comenzi pentru a testa: Update-FormatData -prepend c:\CustomViewB format pslxml -ComputerName gazdă locală Rezultatul final ar trebui să arate cam așa: СотриterName СотриterName Drive Drive CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT \\?\Volume{ d f - e b- C:\Temp\ C:\ D:\ \\?\Volume{ d f - e b- C:\Temp\ C:\ D:\ FreeSpace(GB) Size(GB) FreeSpace(GB) Size(GB) Rețineți că anteturile de coloană nu sunt exact aceleași cu numele proprietăților obiectului personalizat Modificați funcția dumneavoastră avansată Lab C din capitolul , astfel încât obiectul de ieșire al matriței să aibă numele de tip matriță MOL ServiceProcessInf o Apoi, creați o vizualizare personalizată într-un fișier numit C:\CustomViewC format pslxml Vizualizarea personalizată ar trebui să afișeze obiecte de tip matriță MOL ServiceProcessInf o într-un format de tabel, afișând numele computerului, numele serviciului, numele afișat, numele procesului și dimensiunea virtuală a procesului În plus față de formatul tabelului, creați o vizualizare de listă în același fișier, care afișează proprietățile matriței în ordinea următoare: Numele calculatorului Nume (redenumit ca Serviciu) Numele de afișare Numele procesului VMSize Număr de fire PeakPageFile În partea de jos a fișierului script, adăugați aceste comenzi pentru a testa: Update-FormatData -prepend c:\CustomViewC format pslxml -ComputerName gazdă locală -ComputerName gazdă locală | Format-List Rezultatul final ar trebui să arate cam așa pentru tabel ComputerName Service Nume afișat ProcessName VM Numele calculatorului Serviciu Numele de afișare Numele procesului CLIENTUL AudioEndpointBuilder Windows Audio Endpoint Builder svchost exe CLIENT AudioEndpo Windows Audio E svchost exe CLIENT BFE Base Filtering svchost exe CLIENT BITS Background Inte svchost exe CLIENT Browser Computer Browser svchost exe Și ca tiiis pentru listă: VMSize Număr fire: PeakPageFile: Rețineți că, conform specificațiilor de proiectare din capitolul , nu toate proprietățile obiectului sunt afișate implicit și că unele titluri de coloane sunt diferite de numele proprietăților reale Laboratoarele A, B și C pentru capitolele până la se bazează pe ceea ce sa realizat în capitolele anterioare Dacă nu ați găsit un laborator dintr-un capitol anterior, vă rugăm să faceți acest lucru Apoi verificați rezultatele cu soluții eșantion pe MoreLunches com înainte de a trece la următorul laborator din secvență Am construit Get - Systemlnf o de câteva capitole acum și l-am testat inserând o linie, la sfârșitul scriptului nostru, care rulează funcția die Este timpul să ne îndepărtăm de tiiat și să trecem la ceva mai formal, pachet distribuibil pentru comanda noastră De asemenea, trebuie să găsim o modalitate de a face ca fișierul XML de vizualizare personalizată să se încarce automat în memorie atunci când cineva dorește să folosească instrumentul nostru In tiiis capitol, vom realiza botii Introduse în PowerShell v , modulele sunt mijloacele preferate de extensie ale shell-ului (depășind tehnologia originală de extensie PSSnapin) Modulele pot fi, în multe cazuri, copiate de fișiere radier tiian care necesită pachete sau instalatori, ceea ce face ca modulele să fie ușor de distribuit Cel mai bine, din perspectiva noastră, modulele pot fi scrise în script, ceea ce înseamnă că nu trebuie să fii un dezvoltator C# pentru a crea unul Când vine vorba de module, o mare parte din capacitatea PowerShell se bazează pe tehnici relativ slabe Modulele trebuie să urmeze o anumită convenție de denumire și locație pentru ca PowerShell să le „vadă” Acest lucru îi poate atrage pe oameni într-adevăr pentru o buclă la început - este greu de înțeles că PowerShell poate deveni sensibil la probleme precum numele folderelor și numele fișierelor Dar tiiat asa este Pentru ca PowerShell să utilizeze pe deplin tiiem, modulele trebuie să locuiască într-o anumită locație De fapt, pot exista mai multe locații; Variabila de mediu PSModulePath definește locațiile permise Nu există conținutul implicit al variabilei: PS C:\> get-content env:\psmodulepath C:\Utilizatori\donj ones\Documents\WindowsPowerShell\Modules;C:\Windows\system \Win dowsPowerShell\vl \Modules\ Puteți modifica această variabilă de mediu - folosind fie Windows, fie un obiect de politică de grup (GPO) - pentru a conține căi suplimentare Unele produse PowerShell de la terțe părți pot modifica și această variabilă Conținutul variabilei trebuie să fie o listă de căi separate prin punct și virgulă în care pot fi stocate module Pentru acest capitol, vom începe cu primul padi implicit, care se află în C:\Users\ '\Documents\WindowsPowerShell\ Modules Acest padi nu există în mod implicit: va trebui să îl creați pentru a începe să îl utilizați În Windows Explorer, când faceți clic pe biblioteca Documente, accesați de fapt două foldere: Public Documente și My Documente (sau doar Documente) Calea modulului din PSModulePath se referă numai la locația My Documente Deci, dacă utilizați Windows Explorer pentru a crea foldere de matrițe în calea diis, asigurați-vă că extindeți biblioteca Documente și selectați în mod explicit Documentul meu sau Documentul Am creat o comandă la îndemână pentru a crea padi-ul necesar: PS C:\> New-Item -type directory -path (((get-content env:\psmodulepath) Ьф -split ; ) [ ] ) Director: C:\Users\donj ones\Documents\WindowsPowerShell Mod LastWriteTime Lungime Nume d : Module Rețineți că diat diis padi este specific utilizatorului; dacă doriți să vă plasați modulele într-o locație partajată, accesibilă de mai mulți utilizatori, atunci este bine să adăugați acea parte la PSModulePath pentru utilizatorii anumiți A face acest lucru cu un GPO ar fi cel mai ușor și este bine să puneți căi UNG în PSModulePath și trebuie să creați o unitate de rețea Numele modulelor ar trebui să fie formate din litere, cifre și caractere de subliniere, deși modulele furnizate de Microsoft tind să fie denumite numai cu litere Nu folosiți nume de module care conțin spații (nu este ilegal din punct de vedere tehnic, dar îngreunează lucrul acesta) Odată ce ați găsit un nume bun pentru modulul dvs (vom folosi MOLTools), trebuie să creați un folder pentru modul În multe privințe, folderul pe care îl creați este modulul: dacă distribuiți acest lucru altor utilizatori, de exemplu, este întregul folder pe care îl veți distribui Dosarul trebuie creat într-una dintre părțile listate în PSModulePath; dacă puneți folderul tiie module în altă parte, atunci acesta nu va participa la numeroase funcții PowerShell (cum ar fi descoperirea automată a modulelor, încărcarea automată, ajutor actualizabil și așa mai departe) Vom trece la calea permisă pentru modul și vom crea un folder pentru MOLTools: PS C:\> cd \users\donjones\Documents\WindowsPowerShell\Modules PS C:\users\donjones\Documents\WindowsPowerShell\Modules> mkdir cmdlet mkdir la poziția a conductei de comandă Furnizați valori pentru următorii parametri: Calea[ ]: MOLTools Calea[ ]: Director: C:\users\donj ones\Documents\WindowsPowerShell\Modules Mod LastWriteTime Lungime Nume d : MOLTools Am ales numele MOLTools după o gândire serioasă Rețineți că convenția de denumire a comenzilor din PowerShell permite un prefix pe porțiunea substantiv a numelor comenzilor Acest prefix este conceput pentru a împiedica suprapunerea numelor de comenzi Deci, comanda noastră Get-Systemlnfo ar trebui să fie numită cumva, cum ar fi Get-MOLSystemlnfo MOL înseamnă „Luna de prânz” și este un prefix substantiv care credem că este puțin probabil să fie folosit de mulți odieri Acest lucru îl face privat pentru noi (deși nu există nicio modalitate de a ne impune dreptul de proprietate asupra ei) Folosirea MOL ca prefix ne va ajuta să ne asigurăm că comanda noastră poate coexista în mod pașnic cu orice comenzi Get-Systemlnfo pe care altcineva le visează După ce am ales MOL ca prefix substantiv, este logic să îl includem și în numele modulului nostru În acest fel, numele modulului însuși oferă un indiciu cu privire la prefixul substantivului folosit de comenzile din modulul die Asigurați-vă că puteți crea un folder de modul MOLTools după cum urmează De asemenea, luați în considerare prefixul pe care l-ați putea folosi pentru comenzile și modulele organizației dvs Cu folderul nostru de module creat, putem începe să adăugăm conținut la acesta Vrem să putem încărca modulul diis rulând Import-Module MOLTools sau încercând să rulăm una dintre comenzile din modulul die (Get-Systemlnfo sau Get-MOLSystemlnfo dacă îl redenumim) Pentru ca acest lucru să funcționeze, trebuie să înțelegem puțin despre modul în care PowerShell încarcă modulele În primul rând, dacă un modul este localizat într-un padi nestandard (diat este, un padi care nu este listat în PSModulePath), va trebui întotdeauna să încărcăm manual modulul die Să presupunem că am stocat folderul modul în C:\MyStuflf Ar trebui să rulăm Import-Module C:\MyStuff\ MOLTools pentru a încărca modulul, iar PowerShell nu l-ar putea încărca automat pentru noi De aceea, este mai bine să mergeți cu una dintre căile de modul suportate sau să adăugați o nouă cale acceptată la variabila de mediu PSModulePath În acest fel, putem pur și simplu să rulăm Import-Module MOLTools, sau pur și simplu să rulăm una dintre comenzile modulelor die, pentru a încărca modulul Când rulați Import-Module sau când PowerShell încearcă să încarce automat un modul pentru dvs , shell-ul caută în folderul modulului dvs unul dintre elementele și arată în această ordine specifică: Un modul manifest, care în cazul nostru ar fi MOLTools psdl Rețineți că numele fișierului trebuie să se potrivească cu numele folderului modulului, MOLTools Un modul binar, care în exemplul nostru ar fi MOLTools dll, dacă am folosi un binar compilat, ceea ce nu suntem Din nou, numele fișierului trebuie să fie numele complet al modulului plus extensia numelui fișierului Un modul de script, care pentru noi ar fi MOLTools psml Încă o dată, vedeți că numele fișierului trebuie să fie numele complet al modulului, exact așa cum este numit folderul modulului, plus extensia numelui de fișier psml Acesta este partea care aruncă cu adevărat oamenii Vedem că studenții pun ceva de genul Test psml în folderul \Modules\MOLTools și pur și simplu nu va funcționa Cea mai mare parte a magiei PowerShell se bazează pe folderul modulului care se află într-una dintre căile acceptate și pe conținutul modulului având același nume cu acel folder Evitați să introduceți module în cealaltă cale predefinită, care se află sub C:\Windows\System —acea locație este rezervată utilizării de către Microsoft Lista arată fișierul nostru script curent, pe care încă îl numim Test psl Observați că ne-am redenumit comanda în Get-MOLSystemlnfo (evidențiată cu caractere aldine) și am eliminat linia finală a scriptului care a fost folosit pentru a rula funcția Salvăm acest lucru ca G:\Users\donjones\WindowsPowerShelI\Modules\MOLTools\MOLTools psml - cu alte cuvinte, transformându-l într-un modul de script funcția Get-MOLSystemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = 'c:\retry txt', [comuta]$LogErrors ) BEGIN { Write-Verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scriere-verboză „Început blocul PROCES” pentru fiecare ($computer în $numecomputer) { Scriere-verboză „Interogare $computer” Încercați { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -erroraction Stop } Captură { $totul ok = $fals Avertisment de scriere „$computer a eșuat” if ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați avertisment de scriere „Logged to $ErrorLog” } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Proprietate $props $obj PSObj ect TypeNames Insert( , 'MOL Systemlnfo') Write-Output $obj } } } SFÂRŞIT { } Asta este tot ce trebuie să facem, cu condiția ca modulul să fie vizibil doar pentru utilizatorul conectat în prezent Din nou, dacă am fi vrut ca modulul die să fie partajat între utilizatori, am fi creat un nou padi și am fi adăugat diat la PSModulePath Rularea Import-Module MOLTools și apoi Help Get-MOLSystemlnfo confirmă faptul că modulul nostru se încarcă și funcționează Apoi putem rula Get-MOLSystemlnfo - computername localhost pentru a obține rezultatul comenzii die Dar dacă faci o nouă fereastră shell, nu vei primi vizualizarea tabelului personalizată pe care am creat-o în capitolul anterior Să reparăm problema în continuare Un modul de script este destinat să fie format dintr-un singur fișier PSM și asta este În cazul nostru, conținutul modulului nostru consta din punct de vedere tehnic din MOLTools psml și fișierul de vizualizare XML pe care l-am creat în capitolul anterior Un manifest ne-ar permite să încărcăm corpuri de diose în memorie imediat, așa că haideți să creăm unul Vom începe prin a copia fișierul de vizualizare XML în folderul nostru de module: PS C:\Utilizatori\donjones\Documents\WindowsPowerShell\Modules\MOLTools> сору C:\ test format pslxml \ PS C:\Users\donjones\Documents\WindowsPowerShell\Modules\MOLTools> Îs Director: C:\Utilizatori\donj ones\Documents\WindowsPowerShell\Modules\MOLTools Modul LastWriteTime Lungime Nume -a : -a : MOLTools psml test format pslxml Pare o prostie să ai acel nume încă test format pslxml, așa că haideți să-l redenumim în MOLTools format pslxml — care ajută la conectarea vizuală la fișierul modulului de script: PS C:\Users\donjones\Documents\WindowsPowerShell\Modules\MOLTools> ren \te st format pslxml MOLTools format pslxml PS C:\Users\donjones\Documents\WindowsPowerShell\Modules\MOLTools> Îs Director: C:\Utilizatori\donj ones\Documents\WindowsPowerShell\Modules\MOLTools Modul LastWriteTime Lungime Nume -a : -a : MOLTools format pslxml MOLTools psml Acum să creăm un nou manifest de modul Vom face acest lucru rulând NewModuleManifest și furnizând informațiile necesare folosind parametrii comenzii Rețineți că numele fișierului manifest al modulului trebuie să fie MOLTools psdl pentru ca shell-ul să „vadă” manifestul PS C:\Utilizatori\donjones\Documents\WindowsPowerShell\Modules\MOLTools> New-ModuleManifest -Path MOLTools psdl -Autorul „Don & Jeff -CompanyName „Luna de prânz” -Drepturi de autor „(с) Don Jones și Jeffery Hicks” -Descriere „Modul eșantion pentru luna de prânz” - FormatsToProcess \MOLTools format pslxml -ModuleVersion -Versiunea PowerShell -RootModule \MOLTools psml Am formatat frumos acest lucru pentru a se potrivi în carte, dar ați introduce totul pe o singură linie În afară de -Path, parametrii -FormatsToProcess și -RootModule sunt cei mai importanți -FormatsToProcess este o listă separată prin virgulă de fișiere de vizualizare format pslxml (sau în cazul nostru, doar un singur fișier), iar -RootModule este fișierul „principal” din modulul nostru (în cazul nostru, modulul nostru de script) Modulul rădăcină este un concept important: numai comenzile din modulul rădăcină vor fi făcute vizibile pentru utilizatorii shell Dacă modulul nostru de script a importat alte module, prin includerea comenzilor Import-Module în fișierul script sau în una dintre funcțiile sale, acele module copil nu ar fi vizibile pentru utilizatorii shell (deși cineva ar putea importa manual unul dintre acele module, dacă au vrut să le vadă conținutul) Odată ce ați creat un manifest al modulului, cel mai probabil, o mare parte din acesta este o boiler-plată pe care o puteți reutiliza cu alte module Există o nodiing greșit la copierea și lipirea widi între fișierele psdl și schimbarea numelor fișierelor, după cum este necesar Dar va trebui să creați un nou GUID pentru fiecare manifest, ceea ce este destul de ușor Utilizați comanda diis în die shell pentru a crea una, [guid] : :NewGuid(), și dien сору și lipiți rezultatul în manifest Orice secțiune de care nu aveți nevoie în manifest, le puteți comenta Pentru a testa acest lucru, vom închide consola shell și vom deschide una nouă Figura arată că putem importa modulul tiie, rula comanda tiie și obținem formatat în fișierul nostru de vizualizare XML Succes! Asigurați-vă că puteți urmări până în acest punct și obțineți aceleași rezultate ca și noi Ad'iin st'a o Windows 'owerShel ca \ PS C > iirpo"t-rt , odjle nolțools PS C > Get-MCLSysterC'Tfo -ComputerNaTe local'ost CcrputerNa Mocel rre ОЗ/а^гіоч SP localhost Parallels SoftAar ,, Parallels /ігоиаі , ѳ PS C > Acum că am creat un modul de script, putem profita de alte funcționalități interesante oferite de module De exemplu, chiar acum vom crea o variabilă de modul Acest lucru va funcționa la fel ca variabilele „preferințe” încorporate în shell: variabila va fi încărcată în memorie atunci când modulul este importat și o vom folosi pentru a controla un aspect al comportamentului modulului Următoarea listă arată fișierul script revizuit $MOLErrorLogPreference = 'c:\mol-retries txt' [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, Using the variable Using the variable[șir]$ErrorLog = $MOLErrorLogPreference, [comuta]$LogErrors ) ÎNCEPE { Scrieți-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scriere-verboză „Început blocul PROCES” foreach ($computer în $computername) { Scriere-verboză „Interogare $computer” Încercați { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -erroraction Stop } Captură { $totul ok = $fals Avertisment de scriere „$computer a eșuat” if ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați avertisment de scriere „Logged to $ErrorLog” } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Proprietate $props $obj PSObj ect TypeNames Insert( , 'MOL Systemlnfo') Scrie-Ieșire $obj } } } JMaking the variable visible JMaking the variable visibleSFÂRŞIT { } } Export-ModuleMember -Variable MOLErrorLogPreference Export-ModuleMember -Function Get-MOLSystemlnfo Ceea ce am făcut este să adăugăm o variabilă $MOLErrorLogPreference la modul Nu este definit în cadrul uneia dintre funcțiile modulului, așa că aceasta devine o variabilă la nivel de modul, ceea ce înseamnă că va exista în memoria shell-ului de îndată ce modulul este încărcat Apoi l-am folosit pentru a atribui o valoare implicită parametrului -ErrorLog al comenzii Get-MOLSystemlnfo Acest lucru permite acum unui utilizator să seteze $MOLErrorLogPref erence la o cale și un nume de fișier și ca comanda noastră să le folosească automat ca implicit pentru parametrul -ErrorLog În partea de jos a scenariului revizuit apare o parte importantă În mod implicit, variabilele la nivel de modul sunt private, ceea ce înseamnă că pot fi văzute numai de alte elemente din modul Deoarece intenția noastră este să facem variabila vizibilă la nivel global, trebuie să o exportăm, folosind comanda Export-ModuleMember De îndată ce folosim acea comandă, totul din modul devine privat, ceea ce înseamnă că trebuie să exportăm și funcția Get-MOLSystemlnfo pentru ca și aceasta să fie vizibilă la nivel global Ad'TOiTst'a of: Wi"dows Powe'Shel PS C'\> ipo ort-module moltools PS C,\> dir variabilă \mol* 'Чате Valve MOLErrorLogP r efe , 'eice c:\inol-retries txt PS C \> Get-MOLSystemln-To -ComputerName locallost, NOTONLINE -LogErrors ComputerNa Mfgr Model OSVersipr SP ire localhost Parallels So-f;war Paralele ll^t al , Ѳ UNG: NOTONLINE UNG: Conectat la c:\wol-retries txtl PS C \>: Get-Content JMOLE^rorLogPrefererce NCTONLUE PS C \> Testarea variabilei la nivel de modul Figura arată că totul funcționează Începem prin importul modulului și verificăm pentru a vedea că $MOLErrorLogPreference a fost adăugat la unitatea variabilă Am rulat comanda die, adăugând parametrul die -LogErrors După cum puteți vedea, numele fișierului specificat în $MOLErrorLogPreference a fost creat și trimis cu numele computerului eșuat De asemenea, puteți crea și exporta aliasuri în mucii die în același mod Defme die alias și îl exportați folosind Export-ModuleMember Figura arată testul real: Am eliminat modulul matriței și am testat pentru a ne asigura că și $MOLErrorLogPreference a fost eliminat din carcasa matriței Modulul nostru este complet autonom și poate fi încărcat și descărcat complet la cerere! Adn'ntt'e ocWi'dows' o yerShel J I “ PS C \> imcio^t-modul moltools PS C \> dir variabilă \mcl* hame 'iȘ'lt? MOLE''rorLogpf'e-f : eref'oe c, \Sol-retnes txt PS C > Gec-MO-Systemlr-fo -ComputerName localhostJiOTONLlNE -LogErrors ComouterNa Mfgr Mocei OS ersio" SP ire Localhost Parallels Soft^ar, , Parallels Virtual , NING: NOTONLINE fa ] :NING: Conectat la c:\wol-retries t: PS C '> Get-Content iMQLErrorLogPrefe^ence NU ESTE ONLINE PS C \> remove-module moltools PS C'\> dir variabila'Ampl* PS C \> , Eliminarea modulului din memoria shell-ului Aproape am terminat cu Get-Systemlnfo, dar nu chiar Este o funcție „faceți ceva” și am dori să vă arătăm câteva exemple de funcții „input” și „ieșire” De asemenea, am dori să vă arătăm cum să accesați bazele de date dintr-un script PowerShell și probabil ne putem ocupa de toate acestea în capitolul următor În acest capitol veți asambla un modul numit PSHTools, din funcții și vederi personalizate la care ați lucrat în ultimele câteva capitole Creați un folder în directorul modulului utilizator, numit PSHTools Puneți toate fișierele pe care le veți crea în tiie labs în folderul tiiis Creați un singur fișier pslxml tiiat conține toate definițiile de vizualizare din cele trei fișiere de format existente Caii fisierul PSHTools format pslxml Va trebui să fii atent Fiecare vizualizare este definită de etichetele Aceste etichete și tot ce se află între etichete ar trebui să meargă între etichetele Creați un singur fișier modul care conține funcțiile din laboratoarele A, B și C din capitolul , care ar trebui să fie cea mai recentă versiune Exportați toate funcțiile din modul Aveți grijă să creați numai funcția În fișierul modulului, definiți, de asemenea, aliasuri pentru funcțiile dvs și exportați-le Creați un manifest de modul pentru modulul PSHTools care încarcă modulul și fișierele cu format personalizat Testați modulul urmând acești pași: Importă modulul Lise Get-Command pentru a vizualiza comenzile modulului Rulați ajutor pentru fiecare alias Rulați fiecare alias de comandă utilizând localhost ca nume de computer și verificați dacă este întins Scoateți modulul Au dispărut comenzile și variabilele? După ce ați terminat aceste laboratoare, vă rugăm să verificați eșantionul de soluții la Deoarece veți continua să construiți pe aceste funcții în unele dintre capitolele următoare, este important să aveți soluția corectă (sau aproape de ea) înainte de a continua Ne vom îndepărta pe scurt de instrumentele pe care le-am creat și ne vom uita la ceva ce ați putea dori să adăugați la proiectele dvs : citirea și scrierea informațiilor din baze de date De exemplu, poate doriți să interogați o bază de date pentru o listă de nume de computer Sau poate doriți să scrieți rezultatele dintr-o funcție într-o bază de date După cum vă vom arăta, lui PowerShell nici măcar nu îi pasă ce fel de bază de date este! Accesarea bazelor de date din PowerShell necesită utilizarea tehnologiei NET Framework de nivel destul de scăzut Pentru a simplifica tiiat pentru dvs , vă vom oferi un modul de script care reunește toate elementele NET într-un cuplu de funcții avansate PowerShell , care ar trebui să arate și să funcționeze mult ca o comandă nativă PowerShell Va trebui să introduceți mai departe listele de coduri adecvate sau să descărcați codurile de pe (fmd tiiis numele cărții sau imaginea de copertă, faceți clic pe ea și accesați secțiunea Descărcări) În primul rând, trebuie să configurați corect mediul de testare Tehnicile pe care vi le vom arăta vor funcționa pe orice platformă de baze de date pentru care aveți drivere de baze de date compatibile cu NET Framework sau ODBC, dar depinde de dvs să le obțineți și să instalați tiiem Pentru a menține lucrurile simple, vom lucra cu SQL Server Express, care este o ediție gratuită a SQL Server pe care o puteți descărca de pe Micro soft Există o varietate de versiuni disponibile; asigurați-vă că obțineți unul care să fie compatibil cu versiunea dvs a sistemului de operare Windows De asemenea, este adesea distribuit într-un pachet Express cu instrumente de management, care este cel pe care îl doriți Instrumentele de gestionare oferă o diat GUI simplă pe care o puteți utiliza pentru a configura o bază de date de testare Uneori, instrumentele de gestionare a matrițelor (Management Studio) sunt o descărcare separată și vă recomandăm să instalați diem dacă este cazul lui diat Testăm Widi SQL Server Express cu instrumente pe o ediție pe de biți a Windows SQL Server oferă o instalare normală Express sau o instalare LocalDB și am ales versiunea Express O explicație completă despre SQL Server Express și modul de instalare a acestuia depășește domeniul de aplicare al acestei cărți, dar vă vom ghida cel puțin prin pașii de instalare pe care i-am urmat Dacă nu utilizați Windows , poate fi necesar să utilizați o versiune mai veche a SQL Server Express Verificați cerințele de sistem SQL Server pentru mai multe informații Iată cum am instalat produsul: Am fost la și a descărcat ENU\x \SQLEXPRWT x ENU exe, care este o versiune în limba engleză a SQL Server Express cu instrumente Microsoft poate schimba de-a lungul timpului adresa URL și va fi în cele din urmă înlocuită de versiuni ulterioare; vizitați pentru a căuta „SQL Express ” dacă URL-ul tiiat nu mai funcționează Ne-am asigurat că sistemul nostru avea deja instalate toate cerințele prealabile enumerate Dacă nu faceți acest lucru, programul de instalare vă va solicita de obicei să descărcați și să instalați componentele necesare, care pot include o versiune a NET Framework După descărcare, am făcut dublu clic pe fișierul exe pentru a începe instalarea Rețineți că pașii pe care îi urmăm se aplică numai pentru SQL Server Express; versiunile ulterioare, sau chiar versiunile pachetelor de service, pot avea proceduri ușor diferite Scopul nostru cu această carte nu este să vă învățăm cum să instalați SQL Server; vrem doar să-l punem în funcțiune pe sistemul dvs , astfel încât să aveți cu ce să vă jucați Am selectat opțiunea de a instala o nouă instalare autonomă Am acceptat termenii de licență și am permis instalatorului să verifice actualizările produsului Am ales să includem Serviciile Motorului de baze de date, Instrumentele de gestionare și Conectivitate client SQL Nu am inclus SQL Server Replication sau LocalDB, deși acest lucru nu ar trebui să strice, dacă doriți să le includeți Am instalat o instanță Names, numită SQLExpress, cu un ID de instanță al SQLEXPRESS Aceasta a fost implicită și am păstrat și calea implicită de instalare Am acceptat valorile prestabilite pentru filele Conturi de serviciu și Colare Am acceptat valorile implicite pentru filele de configurare a motorului bazei de date, inclusiv Configurarea serverului, Directoarele de date, Instanțele LTser și FILESTREAM Am acceptat valorile prestabilite pentru Raportarea erorilor Am așteptat ceva timp pentru finalizarea instalării Am creat un folder, C:\SampleData, în care să plasăm baza de date eșantion Ne-am asigurat că contul nostru de utilizator are permisiuni de citire/scriere în folder Puteți accepta aproape setările implicite ale matriței și puteți obține aceeași instalare pe care am făcut-o noi Nu pretindem că tiiis este o instalare perfectă de calitate de producție, dar este perfectă pentru mediul nostru de laborator După finalizarea instalării, va trebui să confirmați numele instanței dvs SQL Server Cel mai simplu mod de a face tiiat este să te uiți la o listă de servicii care rulează pe computerul tău , deoarece tiiat vă va arăta toate instanțele SQL Server instalate Am rulat Get - Service, cu următoarele rezultate: PS C:\Windows\system > get-service -name mssql* | selectați numele Nume MSSQL$SQLEXPRESS Aceasta arată că avem un serviciu SQL Server care rulează cu ID-ul de instanță SQLEXPRESS (care este ceea ce i-am spus instalatorului să creeze, așa că nu ar trebui să fie surprinzător) Numele fitil al instanței tiiis este \SQLEXPRESS sau localliost SQI EXPRESS dacă vă conectați local Va trebui să știți asta pentru a construi șirul de conexiune corect mai târziu Pentru moment, deschideți SQL Server Management Studio (ar trebui să aibă o pictogramă în meniul Start odată ce instalarea este finalizată) Vi se va cere să vă conectați, așa cum se arată în figura Am furnizat numele instanței Ic> si SQI EXPRESS și l-am lăsat să folosească acreditările noastre Windows (care este tot ce i-am spus instalatorului că vrem să-l permitem) Z VicosoftS ТІ гл S uo’o * //‘"oo-rfsPowerS'ieL * Modties MO Da aoase MC ’oos РмЬіс Doewws t> Muște bOPicures P H /'«ecs * J Cornpv e t>rj Local D'sx :C) l Hem > ТІ гл S uo’o * //‘"oo-rfsPowerS'ieL * Modties MO Da aoase MC ’oos РмЬіс Doewws t> Muște bOPicures P H /'«ecs * J Cornpv e t>rj Local D'sx :C) l Hem În continuare, vom pune câteva rânduri de date în baza de date Închideți fereastra de interogare în care lucrați și deschideți una nouă făcând din nou clic pe acel buton Interogare nouă Apoi, introduceți (sau lipiți) codul de la lista următoare în fereastra de interogare Utilizați [Inventar] Merge INSERT INTO Computers (nume computer) VALUES ('localhost') INSERT INTO Computers (nume computer) VALUES ('localhost') INSERT INTO Computers (nume computer) VALUES („nu este online”) Încă o dată, faceți clic! (Executați) pentru a rula interogarea diis și asigurați-vă că rulează fără eroare Odată ce ați terminat, ar trebui să fiți gata să începeți să testați și să utilizați PowerShell Lista este un modul de script creat pentru a simplifica accesul la baza de date Vă sugerăm să salvați fișierul diis pe computer ca\LTsers\ \Documents\WindowsPowerShelI\ Modules\MOLDatabase\MOLDatabase psml, unde este numele dvs de utilizator în Windows Aceasta este aceeași structura de folder în care se află modulul PSHTools, din capitolul anterior Amintiți-vă, folderul MOLDatabase ar trebui să fie la același nivel cu folderul MOLTools, iar MOLDatabase psml ar trebui să intre în folderul MOLDatabase Figura arată cum arată diis în Windows Explorer L' • MOLDdatabase Hcn Get-MOLDatabaseData -connectionString $MOLConnectionString -isSQLServer -interogare „SELECTARE nume computer FROM computere” } funcția Set-MOLInventorylnDatabase { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [obiect[]]$inputObj ect ) PROCES { foreach ($obj în $inputobject) { $query = "ACTUALIZAȚI SETATE calculatoarele osversion = '$($obj osversion)', spversion = '$($obj spversion)', producător = '$($obj manufacturer)', model = '$($obj model)' WHERE computername = '$($obj computername)'" Scriere-Verbose "Interogarea va fi $query" Invoke-MOLDdatabaseQuery -connection $MOLConnectionString -isSQLServer -interogare $interogare } } } funcția Get-MOLSystemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, ValueFromPipelineByPropertyName=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = $MOLErrorLogPreference, [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scriere-verboză „Început blocul PROCES” pentru fiecare ($computer în $numecomputer) { Scriere-verboză „Interogare $computer” Încercați { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -erroraction Stop } Captură { $totul ok = $fals Avertisment de scriere „$computer a eșuat” if ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați avertisment de scriere „Logged to $ErrorLog” } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Proprietate $props $obj PSObj ect TypeNames Insert( , 'MOL Systemlnfo') Write-Output $obj } } } SFÂRŞIT { } } Export-ModuleMember -Variable MOLErrorLogPreference Export-ModuleMember -Function Get-MOLSystemlnfo, Get-MOLComputerNamesFromDatabase, Set-MOLInventorylnDatabase Trebuie să explicăm ce am făcut, dar mai întâi să testăm: PS C:\> remove-module mol* PS C:\> import-module moltools PS C:\> Get-MOLComputerNamesFromDatabase | Get-MOLSystemlnfo | Set-MOLInventorylnDatabase AVERTISMENT: nu a reușit online Perfect! Cel din ieșire provine probabil din funcția noastră de bază de date și este un indicator de succes; am fi putut să-l transmitem pe Out-Null pentru a o suprima, dar în acest stadiu este plăcut să vedem că se întâmplă ceva Deci, ce a făcut ca acest lucru să funcționeze? Să luăm niște animale de companie din MOLTools psml, începând cu asta: $MOLConnectionString = „server=localhost\SQLEXPRESS;database=inventory;trusted connection=True” Import-Module MOLDdatabase Acest text din partea de sus a fișierului setează șirul nostru de conexiune implicit și încarcă modulul MOLDatabase Conținutul MOLDatabase nu va fi vizibil pentru utilizatorul shell, deoarece este intern la MOLTools Urmează prima noastră funcție nouă: funcția Get-MOLComputerNamesFromDatabase { Get-MOLDatabaseData -connectionString $MOLConnectionString -isSQLServer -interogare „SELECTARE nume computer FROM computere” } Am păstrat acest lucru simplu în scopuri ilustrative; ar trebui să îi adăugăm un ajutor mai bun bazat pe comentarii, așa că nu ezitați să extindeți ceea ce am început Acest lucru primește doar toate numele computerelor din baza de date Iese fiecare ca obiect cu o proprietate ComputerName Aceasta va necesita o modificare minoră a parametrilor lui Get-MOLSystemlnf o: [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, ValueFromPipelineByPropertyName=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir [] ] $ComputerName, Nu, am adăugat atributul ValueFromPipelineByParameterName, permițând parametrului -ComputerName al funcției să accepte conținutul unei proprietăți introduse în ComputerName S-ar putea, pe termen lung, să dorim să eliminăm și acel atribut Val idateCount (), deoarece este probabil că baza noastră de date va conține în cele din urmă mai mult de computere Urmează funcția care salvează datele înapoi în baza de date: funcția Set-MOLInventorylnDatabase { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True) ] Obiect [obiect [] ] $inputobject remove-module mol* PS C:\> import-module moltools PS C:\> Get-MOLComputerNamesFromDatabase | Get-MOLSystemlnfo | Set-MOLInventorylnDatabase AVERTISMENT: nu a reușit online Perfect! Acest lucru ilustrează cât de simplu este să puneți ceva împreună, să îl testați și apoi să îl modificați dacă nu sunteți mulțumit de primele rezultate Și după cum puteți vedea, cu puțin ajutor din partea funcțiilor wrapper din MOLDatabase, putem începe să lucrăm cu bazele de date destul de ușor! Nu există laborator pentru acest capitol; utilizarea efectivă a bazelor de date va varia foarte mult în funcție de nevoile dvs exacte și de sarcinile pe care doriți să le finalizați Dar funcțiile de matriță pe care le-am furnizat în acest capitol ar trebui să vă ofere toate modelele de matrițe și șabloanele de care aveți nevoie pentru a începe să utilizați bazele de date în propriile Scripturi Nu vă vom învăța nimic nou în acest capitol În schimb, am dori să luăm o scurtă pauză de la învățare și să ne concentrăm pe consolidarea a ceea ce ați făcut până acum, folosind un exemplu diferit Acest capitol, Dien, este practic un laborator gigant Veți parcurge fiecare pas al procesului de fabricare a matrițelor (așa cum l-am acoperit până acum) și veți crea un instrument complet nou pentru dvs În exemplul de răspunsuri de laborator oferit la http://MoreLunches com , vă vom oferi un exemplu de script pentru fiecare secțiune a capitolului respectiv În acest fel, dacă vă rătăciți, puteți ajunge din urmă uitându-vă la exemplul nostru pentru punctul respectiv Acest capitol va necesita dacă aveți un computer Windows sau Windows Server Veți proiecta un instrument care utilizează modulul SmbShare inclus în versiunile diose de Windows Sarcina dvs este să creați o funcție numită Get-RemoteSmbShare Ar trebui să accepte unul sau mai multe nume de computer, mai ales pe un parametru -ComputerName sau din conductă, și să preia o listă de foldere partajate curente de la fiecare computer specificat Ieșirea trebuie să includă numele fiecărui computer, numele partajării, descrierea și calea către partajare Deoarece comenzile din modulul SmbShare nu au în sine parametrii -ComputerName, veți utiliza PowerShell Remoting (invoke-Command) În scopul tiiis lab, presupuneți că fiecare computer pe care trebuie să îl interogați are Power Shell Remoting activat, cu configurația implicită a HTTP necriptat prin portul În scopuri de testare, activați Remoting pe computer rulând Enable-PSRemoting ( tiiis trebuie făcut ca administrator într-o sesiune ridicată și trebuie să vă asigurați că comanda se finalizează fără eroare) Când testați funcția dvs pe parcursul acestui capitol, faceți acest lucru furnizând „localhost” ca nume al computerului Începeți să scrieți funcția dvs avansată Deocamdată, nu-l includeți într-un modul În schimb, includeți-l într-un script simplu psl care este salvat în directorul dvs C:\ În partea de jos a scriptului dvs , după închiderea morții } pentru funcția die, introduceți următoarele pentru a testa funcția die: Get-RemoteSmbShare -computerName gazdă locală,gazdă locală Deoarece localhost este listat de două ori, rezultatul funcției dvs ar trebui să listeze fiecare dintre folderele partajate ale computerului dvs de două ori Modificați funcția Get-RemoteSmbShare pentru a include următoarele caracteristici: Parametrul -ComputerName ar trebui să fie obligatoriu, ceea ce înseamnă că PowerShell ar trebui să solicite o valoare dacă nu este specificată una Parametrul -ComputerName ar trebui să accepte intrarea din conducta ByValue Adăugați -HostName ca alias pentru parametrul die -ComputerName Asigurați-vă că cel puțin unul și nu mai multe nume de computer sunt specificate de fiecare dată când funcția este rulată Adăugați următoarele linii în partea de jos a scriptului pentru a testa adăugările: Secțiunea Teste „localhostlocalhost” | Get-RemoteSmbShare Get-RemoteSmbShare -host localhost Următoarele ar trebui să solicite un nume; introduceți localhost Get-RemoteSmbShare Următoarele ar trebui să eșueze cu o eroare Get-RemoteSmbShare -Computer unu, doi, trei, patru, cinci, șase, șapte După ce ați terminat de testat modificările, eliminați toate liniile anterioare din scriptul dvs Adăugați ajutor bazat pe comentarii la funcția dvs Get-RemoteSmbShare Includeți cel puțin un rezumat și o descriere și includeți ajutor pentru parametrul pneu -ComputerName Includeți, de asemenea, cel puțin două exemple În partea de jos a anvelopei a scriptului, adăugați următoarea linie pentru anvelope pentru a testa noul ajutor pentru anvelope: Ajutor Get-RemoteSmbShare Eliminați linia de cod tiiat din script după testarea noului ajutor Modificați funcția Get-RemoteSmbShare pentru a include un parametru -ErrorFile Acest parametru ar trebui să accepte un singur șir și ar trebui să fie implicit C:\Errors txt De asemenea, modificați funcția die pentru a detecta orice erori care apar în timpul rulării Invoke-Command Când apare o eroare, funcția die ar trebui să înregistreze numele computerului eșuat la orice nume de fișier specificat în parametrul die -ErrorFile Ar trebui să adauge întotdeauna valori la fișierul diis și nu ar trebui să încerce niciodată să șterge fișierul die Funcția ar trebui să afișeze, de asemenea, un mesaj de avertizare cu numele computerului eșuat și nu ar trebui să încerce să creeze obiecte de ieșire pentru partajările computerului respectiv Nu uitați să actualizați ajutorul bazat pe comentarii pentru a reflecta noul parametru Adăugați următoarele în partea de jos a scriptului pentru a testa această nouă funcționalitate: Get-RemoteSmbShare -computer localhost,NOTONLINE,localhost Asigurați-vă că tiiat NOTONLINE este conectat la C:\Errors txt, apoi eliminați linia anterioară de cod din scriptul dvs Încorporați funcția dvs Get-RemoteSmbShare în modulul PSHTools pe care l-ați creat pentru capitolele anterioare din această carte Când faceți acest lucru, asigurați-vă că adăugați numai funcția tiie în fișierul psml al modulului; nu adăugați niciun cod de testare tiiat în scriptul tiie din secțiunile anterioare ale capitolului tiiis Deschideți o nouă fereastră de consolă PowerShell și rulați Import-Module PSHTools Rulați Get-RemoteSmbShare -computer localhost și asigurați-vă că ieșirea corectă este afișată Felicitări! Ați finalizat nucleul și cea mai importantă parte a acestei cărți! Folosind tehnicile pe care le-ați învățat până la acest punct, ar trebui să puteți construi niște instrumente destul de impresionante În următoarele șapte capitole, vom începe să vă extindem repertoriul de trucuri de fabricare a sculelor, arătându-vă tehnici suplimentare Nu vom mai construi întotdeauna din vechea funcție Get-Systemlnfo, dar credem că veți găsi o mulțime de lucruri interesante cu care să lucrați Cu noțiunile de bază ale confecționării uneltelor aflate sub control, sunteți gata să începeți să explorați unele dintre tehnicile și strategiile mai diferite oferite de PowerShell În următoarele câteva capitole, vom explora aspecte precum fluxul de lucru, depanarea intrării în conductă și multe altele Dacă niciunul dintre aceste capitole nu este destinat să ofere o acoperire cuprinzătoare a subiectelor proprii (fluxul de lucru, de exemplu, are nevoie de o carte întreagă proprie), următoarele capitole vă vor indica în direcția corectă pentru a începe să utilizați funcțiile și capabilitățile avansate ale fliese Până acum, ne-am concentrat pe instrumente care obțin informații, Get-MOLSystemlnf o fiind exemplul nostru de rulare Dar, evident, veți crea și instrumente care fac modificări Când faceți acest lucru, există câțiva pași suplimentari pe care ar trebui să îi faceți pentru a rămâne consecvent în restul PowerShell Ați văzut deja un indiciu de diis: suport pentru -Confirmând -Ce este inclusă funcția noastră Invoke-MOLDatabaseQuery În acest capitol, vă vom ghida prin detalii Vom folosi unele dintre comenzile CIM ale PowerShell din capitolul diis Acestea funcționează împotriva Windows Management Instrumentation (WMI), dar funcționează numai dacă PowerShell Remoting a fost activat pe computer Dacă întâmpinați probleme cu utilizarea lor, puteți trece la o comandă WMI mai veche Vom oferi sfaturi pe parcurs pentru a face acest lucru Priviți ajutorul pentru orice comandă PowerShell care face modificări și este posibil să vedeți bodi -Confirm și -Whatlf incluse în parametrii comenzii die Acești parametri ar trebui să fie acceptați pentru orice comandă care modifică starea sistemului în orice fel - chiar și ceva la fel de simplu ca schimbarea unui fișier de pe disc Din fericire, nu este nevoie să codificați manual parametrii matriței în instrumentele dvs Dacă scrieți o funcție avansată, care este mai mult sau mai puțin tot ceea ce am scris în această carte, doar puțină muncă suplimentară poate implementa acești doi parametri cheie pentru dvs Vom crea un instrument numit Restart-MOLCimComputer Instrumentul nostru va accepta unul sau mai multe nume de computer și va utiliza WMI pentru a reporni tliem Mai exact, vom folosi metoda Reboot () a clasei Win OperatingSystem Această metodă nu acceptă parametri; pur și simplu începe repornirea Suntem conștienți că o comandă Repornire-Computer foarte similară există în mod nativ în PowerShell Tehnica noastră va utiliza familia de cmdlet CIM a PowerShell v , care utilizează protocolul de telecomandă WS-MAN, mai ales orice magie neagră pe care Restart-Computer o folosește pentru a comunica În plus, aveam nevoie de un exemplu simplu, iar diis este ceea ce ne-am gândit! Ori de câte ori începem să construim un instrument, avem tendința de a începe în linia de comandă, rulând comenzi ad-hoc pentru a face diem să funcționeze Deci, vom începe prin a rula comanda diis în consola PowerShell: PS C:\>Invoke-CimMethod -ClassName Win OperatingSystem -MethodName Reboot -ComputerName localhost Un moment vă va spune că nu ar trebui să rulați comanda diis decât dacă ați salvat toate fișierele deschise! Dacă această comandă nu funcționează pe sistemul dvs , atunci este probabil ca PowerShell's Remoting să nu fi fost activat Puteți face asta rulând Enable-PSRemoting ca administrator Sau puteți trece la Invoke-WmiMethod -Class Win OperatingSystem -Name Reboot -ComputerName localhost Va trebui să faceți aceeași înlocuire în lista O repornire rapidă mai târziu și am confirmat că comanda noastră funcționează Acum să construim un instrument din el Vom adăuga conținutul listei la fișierul nostru MOLTools psml, dar vom enumera doar completări aici în loc să listăm întregul conținut al fișierului Includem, de asemenea, ultimele rânduri ale MOLTools psml, care listează articolele exportate ale acestui modul Observați că am adăugat Restart-MOLCimComputer la lista de funcții exportate funcția Restart-MOLCimComputer { [CmdletBinding(SupportsShouldProcess=$True, Confirmlmpact= High )] param( [Parametru(Obligatoriu=$true, ValueFromPipeline=$true)] [șir [] ] $ComputerName PROCES { Pentru fiecare ($computer în $computername) { Invoke-CimMethod -ClassName Win OperatingSystem -MethodName Reporniți -ComputerName $computer } } } Export-ModuleMember -Variable MOLErrorLogPreference Export-ModuleMember -Function Get-MOLSystemlnfo, Get-MOLComputerNamesFromDatabase, Set-MOLInventorylnDatabase, Restart-MOLCimComputer Pentru a menține acest exemplu simplu, nu adăugăm nicio gestionare a erorilor Într-un mediu de producție, ne așteptăm să doriți să faceți asta Probabil că ați dori, de asemenea, să adăugați ajutor bazat pe comentarii și alte detalii pe care le-am acoperit în capitolele precedente Există o singură diferență majoră între acest instrument și celelalte pe care le-am scris, și aceasta este în atributul [CmdletBinding () ] (pe care l-am aldine) Am indicat că această funcție acceptă ShouldProcess, care este ceea ce activează parametrii -Whatlf și -Confirm De asemenea, am definit un Confirmlmpact, setându-l la High Vom discuta acest nivel de impact în secțiunea următoare; deocamdată, să testăm noua noastră funcție Înainte de a face asta, priviți cu atenție ajutorul pentru Invoke-CimMethod Observați că acceptă și -Whatlf și -Confirm, pe care le puteți verifica citind fișierul de ajutor Vom salva fișierul MOLTools psml revizuit și apoi vom intra în consolă Vom elimina modulul MOLTools (în cazul în care este deja încărcat), îl vom importa (pentru a citi în noua versiune) și apoi vom rula funcția noastră Acest lucru va reporni computerul din nou, așa că asigurați-vă că nu există alte fișiere deschise, nesalvate! PS C:\> remove-module moltools Remove-Module : Nu au fost eliminate module Verificați dacă specificația modulelor de eliminat este corectă și că acele module există în spațiul de rulare La linia:l char:l + remove-module moltools + + Categorynfo : ResourceUnavailable: (:) [Eliminare-Module], I nvalidOperationException + FullyQualifiedErrorld: Modules NoModulesRemoved,Microsoft PowerShe Comands RemoveModuleCommand PS C:\> import-module moltools PS C:\> Restart-MOLCimComputer -ComputerName gazdă locală Mesajul de eroare ne spune că modulul nu a fost deja încărcat când am încercat să-l eliminăm Asta e fme Și pleacă! Acest lucru confirmă că comanda noastră a funcționat Acum să încercăm să-l rulăm cu -Whatlf și -Confirm: PS C:\> import-module moltools PS C:\> Restart-MOLCimComputer -ComputerName localhost -whatif Ce se întâmplă dacă: Se efectuează operația „Invoke-CimMethod: Reboot” pe țintă „Win O peratingSystem” PS C:\> Restart-MOLCimComputer -ComputerName localhost -confirm A confirma Sigur doriți să efectuați această acțiune? Efectuarea operației „Invoke-CimMethod: Reboot” pe țintă „Win OperatingSystem” [Y] Da [A] Da tuturor [N] Nu [L] Nu tuturor [S] Suspendare [?] Ajutor (implicit este „Y”):n PS C:\> De data aceasta, puteți vedea rezultatul ce se întâmplă, precum și promptul de confirmare Aceasta ilustrează câteva puncte importante: Specificând SupportsShouldProcess=$True în atributul nostru [CmdletBinding () ] , permitem lui Restant-CimComputer să accepte parametrii -Whatlf și -Confirm Deoarece comanda noastră internă, Invoke-CimMethod, acceptă deja -Whatlf și -Confirm pe cont propriu, nu trebuie să facem nimic altceva -Whatlf sau -Confirm transmise instrumentului nostru este transmis oricărei comenzi interne care acceptă și parametrii matriței Dacă examinați ieșirea ce se întâmplă și muriți promptul de confirmare, veți vedea că de fapt este Invoke-CimMethod diat care declanșează ieșirea Acest efect de retragere funcționează pentru toți parametrii comuni, inclusiv -Verbose, -Debug și odiers Dacă cineva rulează instrumentul dvs cu unul dintre ele, acesta va fi transmis oricăror comenzi din instrumentul dvs Deci, dacă cineva rulează instrumentul tău widi -Verbose, fiecare comandă din interiorul instrumentului die va rula și widi -Verbose, care este aproape exact ceea ce ți-ai dori în mod normal! Să ne întoarcem la nivelul impactului morții Valorile posibile pentru Conf irmlmpact, în atributul [CmdletBinding () ], sunt Low, Medium și High Acesta este o indicație relativă a cât de dăunătoare ar putea fi comanda dvs Dacă intenționați să faceți o modificare minoră, specificați un impact de confirmare pentru Scăzut; dacă faceți o schimbare majoră, cum ar fi repornirea unui computer, ați putea opta pentru High Nu există reguli stabilite cu privire la ce nivel este destinat pentru ce; totul depinde de judecata ta PowerShell are două invariabile încorporate, $WhatIf Pref erence și $Conf irmPref erence Fiecare funcționează puțin diferit: $WhatIf Preference este setat în mod implicit la $False Dacă îl schimbați în $True, aveți toate comenzile care acceptă -Whatlf vor rula ca și cum -Whatlf ar fi fost specificat, chiar dacă nu îl specificați Cu alte cuvinte, schimbă shell-ul în modul implicit Când variabila este setată la $True, puteți rula comenzi cu -Whatlf : $False pentru a dezactiva modul what-if doar pentru comanda tiiat $Conf i rmPref erence este setată implicit la High Când rulați o comandă care acceptă -Confirm, die shell se uită la nivelul de impact al comenzii die Dacă nivelul de impact al comenzii matriței este egal sau mai mare cu conținutul matriței din $Conf irmPref erence, parametrul dien die -Confirm este adăugat automat Deci, o comandă cu un nivel de impact ridicat ar trebui să conducă întotdeauna la un prompt de confirmare, cu excepția cazului în care o rulați cu Widi-Confirm:$False Citind ultimul punct, s-ar putea să dezvolți așteptarea că comanda noastră Restart-CimComputer va afișa întotdeauna un prompt de confirmare La urma urmei, am setatConf irmlmpact la High, nu? Dar dacă apelați primul nostru test al comenzii, computerul a fost repornit fără un prompt de confirmare Ce s-a întâmplat? Secretul constă în modul în care funcționează procesul de transfer Vedeți, Restart-CimComputer nu i-a dat niciodată șansa lui shell să verifice nivelul de impact În schimb, a rulat Invoke-CimMethod Nivelul de impact al acelei comenzi nu este setat la High, așa că nu a declanșat $Conf irmPreference Instrumentul dvs va declanșa automat confirmarea numai atunci când îi spune explicit shell-ului că face ceva care ar putea necesita confirmare La asta ne vom uita în continuare Pentru următorul nostru instrument, vom schimba parola de conectare a unui serviciu Acesta este ceva ce trebuie realizat prin rularea metodei Change () din clasa Win Service a WMI Aruncarea o privire la documentația MSDN pentru clasă ( ), vedem că metoda Change () acceptă numeroase setări Al optulea setează parola de conectare, așa că va trebui să trecem $null pentru primii șapte parametri, așa că nu modificăm niciunul dintre aceștia Putem omite parametrii al nouălea și următorii, pentru că, de asemenea, nu vrem să modificăm acesta Din nou, vom începe prin a testa tiiis în shell - vom modifica serviciul BITS, deoarece acest lucru nu va da peste cap nimic prea sever BITS este cu siguranță folosit într-un mediu de producție pentru, printre altele, Windows Update Ne simțim confortabil să o încurcăm în mediul nostru de laborator, dar acest lucru nu este ceva cu care ar trebui să experimentezi pe un computer live PS C:\> Get-WmiObject -Class Win Service -ComputerName Localhost -Filter "name='BITS'" | Invoke-WmiMethod -Name Change -ArgumentList $null,$null,$nu , $null, $null, $null, $null, „P@sswOrd” Invoke-WmiMethod: șirul de intrare nu a fost într-un format corect La linia:l char: + Get-WmiObject -Class Win Service -ComputerName Localhost -Filter "nume= BITS" + + Categorynfo : NotSpecified: (:) [Invoke-WmiMethod], Forma tExcepție + FullyQualifiedErrorld: System FormatException, Microsoft PowerShell Comenzi InvokeWmiMethod Am ales să folosim comanda WMI, mai degrabă decât echivalentul CIM, dintr-un motiv specific: parametrul -ArgumentList al Invoke-WmiMethod nu poate face față valorilor $null De aceea am primit acest mesaj de eroare Invoke-CimMethod acceptă argumente într-un format diferit, în special pentru a evita această problemă Pentru moment, ne vom preface că scriem un instrument de care are nevoie pentru a rula pe computere mai vechi (cum ar fi Windows XP), astfel încât cmdleturile CIM mai noi nu sunt o opțiune Aceasta înseamnă că, în loc să folosim Invoke-WmiMethod, va trebui să invocăm manual metiiodul Change () a obiectului Aceasta prezintă o problemă: Deși Invoke-WmiMethod acceptă -Whatlf și -Confirm, o metodă obiect nu Va trebui să implementăm manual suportul pentru acești doi parametri Următoarea listă arată noua funcție pe care o adăugăm la MOLTools psml, împreună cu ultimele două comenzi din acel fișier, care ne exportă funcțiile funcția Set-MOLServicePassword { [CmdletBinding(SupportsShouldProcess=$True, Confirmlmpact='Mediu')] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [șir [] ] $ComputerName, [Parametru(Obligatoriu=$True)] [șir]ȘServiceName, [Parametru(Obligatoriu=$True)] [șir]ȘNewPassword ) PROCES { foreach ($computer în $computername) { $svcs = Get-WmiObject -ComputerName Școmputer -Filtru "name='$servicename'" -Clasa Win Service foreach ($svc în $svcs) { if ($psCmdlet ShouldProcess("$svc pe Școmputer")) { $svc Change($null, $null, $null, $null, $null, $null, $null, ȘNewPassword) | Out-Null } } } } } Export-ModuleMember -Variable MOLErrorLogPreference Export-ModuleMember -Function Get-MOLSystemlnfo, Get-MOLComputerNamesFromDatabase, Set-MOLInventorylnDatabase, Restart-CimComputer, Set-MOLServicePassword Din nou, am omis lucruri precum ajutorul bazat pe comentarii și gestionarea erorilor , doar pentru a menține acest exemplu mai simplu Să testăm asta imediat Vom începe într-o nouă consolă PowerShell, vom încărca modulul și vom vedea ce se întâmplă: PS C:\> Set-MOLServicePassword -ServiceName BITS -NewPassword "P@sswOrd" -C omputerName localhost La asta ne așteptam Am setat impactul de confirmare la Mediu și știm că valoarea implicită a $Conf irmPreference este ridicată, așa că nu ne așteptam la o solicitare de confirmare Acum să schimbăm acea variabilă și să încercăm din nou comanda: PS C:\> $ConfirmPreference = „Mediu” PS C:\> Set-MOLServicePassword -ServiceName BITS -NewPassword "P@sswOrd" -C omputerName localhost A confirma Sigur doriți să efectuați această acțiune? Efectuarea operației „Set-MOLServicePassword” pe țintă „\\DONJONESlD \root\cimv :Win Service Name="BITS" pe localhost” [Y] Da [A] Da tuturor [N] Nu [L] Nu tuturor [S] Suspendare [?] Ajutor (implicit este „Y”): n PS C:\> Perfect Cu $Conf irmPreference la Mediu, nivelul de impact al comenzii noastre a fost egal sau mai mare decât variabila și astfel confirmarea a avut loc automat Acum să readucem variabila la valoarea implicită și să încercăm să rulăm comanda în modul ce se întâmplă: PS C:\> $ConfirmPreference = „Ridicat” PS C:\> Set-MOLServicePassword -ServiceName BITS -NewPassword "P@sswOrd" -C omputerName localhost -Whatlf Ce se întâmplă dacă: Se efectuează operația „Set-MOLServicePassword” pe țintă „\\DONJONE SlD \root\cimv :Win Service Name="BITS" pe localhost” PS C:\> Excelent Acum pentru confirmări: PS C:\> Set-MOLServicePassword -ServiceName BITS -NewPassword "P@sswOrd" -C omputerName localhost -confirm A confirma Sigur doriți să efectuați această acțiune? Efectuarea operației „Set-MOLServicePassword” pe țintă „\\DONJONESlD \root\cimv :Win Service Name="BITS" pe localhost” [Y] Da [A] Da tuturor [N] Nu [L] Nu tuturor [S] Suspendare [?] Ajutor (implicit este „Y”):n PS C:\> Minunat! Sau, după cum spune prietenul nostru Spike, $ GREAT! Acum să vedem cum funcționează Magia este cuprinsă într-o singură linie: if ($psCmdlet ShouldProcess("$svc pe $computer")) { $psCmdlet este un obiect încorporat care reprezintă funcționalitatea cmdlet-ului shell-ului pentru instrumentul nostru Apelând metoda ShouldProcess (), informăm shell-ul că suntem pe cale să facem ceva periculos Introducem o descriere text a ceea ce modificăm (ținta), astfel încât promptul de confirmare și rezultatul de tip what-if poate fi mai informativ Făcând referire la $svc în ținta noastră, afișăm serviciul complet WMI padi și numele Pentru ceva mai scurt, ați putea pune „$($svc name) pe $computer” în schimb Când se execută Shouldprocess (), PowerShell efectuează câteva verificări: Dacă comanda die a fost rulată cu -Whatlf, Shouldprocess () returnează False, împiedicând executarea codului din construcția die If Shell-ul afișează rezultatul ce se întâmplă dacă, folosind descrierea țintei transmisă la Shouldprocess () Dacă comanda a fost executată cu -Confirm, Shouldprocess () afișează promptul de confirmare și returnează Adevărat numai dacă utilizatorul selectează Da sau Da la Toate la prompt Dacă comanda tiie nu a fost rulată cu -Confirm, dar nivelul de impact al comenzii este egal sau mai mare decât $Conf irmPref erence, atunci shell-ul face oricum promptul de confirmare Deci, când trebuie să includeți tiiis If construct și tiie Shouldprocess ()? Dacă comanda dvs rulează doar alte comenzi care acceptă nativ -Whatlf și -Confirm (verificați fișierele lor de ajutor pentru a fi sigur), nu aveți nevoie de tiie If construct sau Shouldprocess () Doar includeți SupportsShouldProcess în atributul dvs [CmdletBinding () ], așa cum am făcut cu funcția noastră Restart-MOLCimComputer Dacă comanda dvs include alte comenzi care acceptă -Whatlf și -Confirm, dar doriți să specificați un nivel de impact mai mare decât acele comenzi declară nativ, includeți acele comenzi în construcția If tiiat folosește Shouldprocess () În atributul dvs [CmdletBinding () ], includeți SupportsShouldProcess și Conf irmlmpact dorit Dacă comanda dvs rulează metode obiect sau comenzile tiiat nu acceptă în mod nativ -Whatlf și -Confirm, atunci includeți-l în construcția If tiiat folosește Shouldprocess () Atributul dvs [CmdletBinding () ] trebuie să includă SupportsShouldProcess și un nivel de impact Doar pentru a vă asigura că sunteți pe aceeași pagină în continuare, următoarea listă conține fișierul complet MOLTools psml până la punctul tiiis $MOLErrorLogPreference = 'c:\mol-retries txt' $MOLConnectionString = „server=localhost\SQLEXPRESS;database=inventory;trusted connection=True” Import-Module MOLDdatabase funcția Get-MOLComputerNamesFromDatabase { Get-MOLDatabaseData -connectionString $MOLConnectionString -isSQLServer -interogare „SELECT numere computer FROM computere” } funcția Set-MOLInventorylnDatabase { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [obiect[]]$inputObj ect ) PROCES { foreach ($obj în $inputobject) { $query = "ACTUALIZAȚI SETATE calculatoarele osversion = '$($obj osversion)', spversion = '$($obj spversion)', producător = '$($obj manufacturer)', model = '$($obj model)' WHERE computername = '$($obj computername)'" Scriere-Verbose "Interogarea va fi $query" Invoke-MOLDdatabaseQuery -connection $MOLConnectionString -isSQLServer -interogare $interogare } } } funcția Get-MOLSystemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True, ValueFromPipelineByPropertyName=$True, HelpMessage="Numele computerului sau adresa IP")] [ValidateCount( , )] [Alias('nume gazdă')] [șir[]]$ComputerName, [șir]$ErrorLog = $MOLErrorLogPreference, [comuta]$LogErrors ) ÎNCEPE { Scrie-verbose „Jurnalul de erori va fi $ErrorLog” } PROCES { Scriere-verboză „Început blocul PROCES” pentru fiecare ($computer în $numecomputer) { Scriere-verboză „Interogare $computer” Încercați { $totul ok = $adevarat $os = Get-WmiObject -class Win OperatingSystem -computerName $computer -erroraction Stop } Captură { $totul ok = $fals Avertisment de scriere „$computer a eșuat” if ($LogErrors) { $calculator | Out-File $ErrorLog -Adăugați avertisment de scriere „Logged to $ErrorLog” } } dacă ($totul ok) { $comp = Get-WmiObject -class Win ComputerSystem -computerName $computer $bios = Get-WmiObject -class Win BIOS -computerName $computer $props = @{'ComputerName'=$computer; 'OSVersion'=$os version; SPVersion'=$os servicepackmaj orversion; BlOSSerial'=$bios serialnumber; 'Manufacturer'=$comp manufacturer; Model'=$comp model} Scriere-verboză „Interogări WMI finalizate” $obj = New-Object -TypeName PSObject -Property $props $obj PSObj ect TypeNames Insert( , 'MOL Systemlnfo') Write-Output $obj } } SFÂRŞIT { } } funcția Restart-MOLCimComputer { [CmdletBinding(SupportsShouldProcess=$True, Confirmlmpact='Ridicat')] param( [Parametru(Obligatoriu=$true, ValueFromPipeline=$true)] [șir[]]$ComputerName ) PROCES { Pentru fiecare ($computer în $computername) { Invoke-CimMethod -ClassName Win OperatingSystem -MethodName Reporniți -ComputerName $computer } } } funcția Set-MOLServicePassword { [CmdletBinding(SupportsShouldProcess=$True, Confirmlmpact='Medium')] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [șir[]]$ComputerName, [Parametru(Obligatoriu=$True)] [șir]$ServiceName, [Parametru(Obligatoriu=$True)] [șir]$NewPassword ) PROCES { foreach ($computer în $computername) { $svcs = Get-WmiObject -ComputerName $computer -Filter "name='$servicename -Clasa Win Service foreach ($svc în $svcs) { if ($psCmdlet ShouldProcess("$svc pe $computer")) { $svc Change($null, $null, $null, $null, $null, $null, $null, $NewPassword) | Out-Null Export-ModuleMember -Variable MOLErrorLogPreference Export-ModuleMember -Function Get-MOLSystemlnfo, Get-MOLComputerNamesFromDatabase, Set-MOLInventorylnDatabase, Restart-CimComputer, Set-MOLServicePassword Asigurați-vă că aveți fișierul tiiis și că puteți rula comenzile așa cum v-am arătat în acest capitol Vom construi din nou pe tiiis în câteva capitole viitoare, așa că este important să vă asigurați că sunteți pe aceeași pagină cu noi În WMI, clasa Win OperatingSystem are o metodă numită Win Shutdown Acceptă un singur argument de intrare, care este un număr care determină dacă metoda se oprește, se oprește, se repornește și se deconectează computerul Scrieți o funcție numită Set-ComputerState Pune-l să accepte unul sau mai multe nume de computer pe un parametru -ComputerName De asemenea, furnizați un parametru -Act ion, care acceptă numai valorile LogOff, Restart, ShutDown sau PowerOff În cele din urmă, furnizați un parametru de comutare -Force (parametrii comutatorului nu acceptă o valoare; fie sunt specificați, fie nu) Când funcția die rulează, interogați Win OperatingSystem de la fiecare computer specificat Nu vă faceți griji cu privire la tratarea erorilor în acest punct; presupunem că fiecare computer specificat va fi disponibil Asigurați-vă că implementați suport pentru parametrii die -Whatlf și -Confirm, așa cum este indicat în capitolul al doilea Pe baza -Acțiunii specificate, executați Win Shutdown mefiiod cu una dintre următoarele valori: Deconectare— Oprire— Reporniți— Oprire— Dacă este specificat parametrul die -Force, adăugați la valorile die Deci, dacă comanda a fost Set-ComputerState -computername localhost -Action LogOff -Force, valoarea die ar fi ( pentru LogOff, plus pentru Force) Execuția Win Shutdown este ceea ce ar trebui inclus în blocul de implementare If pentru suportul -Whatlf și -Confirm Fiți atenți când testați tiiis împotriva localhost - asigurați-vă că ați salvat munca ta, deoarece funcția te va deconecta MemberType Definition MemberType Definition Name Handles Name NPM PM VM ws NounName Company CPU Description FileVersion Path Product ProductVersion Name Handles Name NPM PM VM ws NounName Company CPU Description FileVersion Path Product ProductVersion Cu câteva capitole în urmă, v-am arătat cum să creați o vizualizare de formatare personalizată pentru rezultatul instrumentelor dvs În acest capitol, vom face ceva foarte asemănător prin crearea unei extensii de tip Spre deosebire de vizualizări, care afectează doar prezentarea vizuală a ieșirii, o extensie de tip poate adăuga de fapt funcționalitate obiectelor pe care le scrieți în conductă Credeți sau nu, ați văzut deja extensii de tip în acțiune De exemplu, fugi Get-Process | Get-Member și uită-te la rezultat: TypeName: System Diagnostics Process AliasProperty Handles = Handlecount AliasProperty Name = ProcessName AliasProperty NPM = NonpagedSystemMemorySize AliasProperty PM = PagedMemorySize AliasProperty VM = VirtualMemorySize AliasProperty WS = WorkingSet NoteProperty System String NounName=Proces ScriptProperty System Object Company {get=$t ScriptProperty System Object CPU {get=$this ScriptProperty System Object Descriere {ge ScriptProperty System Object FileVersion {ge ScriptProperty System Calea obiectului {get=$acest ScriptProperty System Object Product {get=$t ScriptProperty System Object ProductVersion Am trunchiat rezultatul pentru a afișa numai extensiile de tip: AliasProperties, NoteProperties și ScriptProperties Alte tipuri de extensii includ ScriptMethods și PropertySets, care nu sunt afișate aici Aceste extensii nu sunt părți native ale System Diagnostice din NET Framework Clasa de proces Dacă căutați documentația clasei diat ( ), nu veți vedea Handle sau Description sau FileVersion Aceste proprietăți sunt adăugate de sistemul de tip extensibil al PowerShell, sau ETS, deoarece shell-ul produce obiecte pentru ieșire Cum face coaja? Depinde Există mai multe tipuri de extindere, fiecare având un scop diferit Unele dintre cele mai importante și scopurile lor sunt următoarele: O AliasProperty oferă o modalitate mai ușoară, sau o modalitate mai consistentă, de a se referi la o proprietate nativă a obiectului De exemplu, Handles este mai ușor decât Handlecount, iar Name oferă o consistență mai bună pe shell decât ProcessName Ambele proprietăți native rămân accesibile, dar AliasProperties ne oferă o modalitate alternativă de a le accesa O NoteProperty conține o valoare statică și este adesea folosită de PowerShell pentru a stoca informații de gestionare În acest exemplu, NounName NoteProperty ține evidența substantivului folosit de comanda tiiat a produs obiectul (Proces) Shell-ul poate folosi acest lucru intern pentru o varietate de scopuri O ScriptProperty execută un cod de script PowerShell pentru a produce o valoare a proprietății De exemplu, Path sapă de fapt adânc în ierarhia informațiilor native a obiectului pentru a dezvălui o informație care este de obicei îngropată destul de adânc O ScriptProperty nu accesează de obicei nicio resursă externă pentru a-și face treaba; doar se reformează sau dezvăluie o parte deja a unui obiect din obiect O ScriptMethod este similară cu o ScriptProperty, deși uneori poate lua o acțiune și nu produce deloc nicio ieșire ScriptMethods sunt puțin mai rare în comenzile native ale PowerShell, deși toate obiectele WMI includ ScriptMethods care se traduc între valori de dată în stil WMI și valori de dată care pot fi citite de om Un PropertySet reunește una sau mai multe proprietăți, care sunt legate într-un fel sau altul De exemplu, rulați Get-Process | Selectați PSResources și veți vedea rezultate diferite din Get-Process, care conține proprietăți legate de consumul de resurse PSResources este un set de proprietăți Extensiile de tip sunt definite în fișiere XML, cum ar fi vizualizările de formatare cu care ați lucrat mai devreme În folderul de instalare al PowerShell (execuți cd $pshome pentru a ajunge acolo), veți fmd Types pslxml, care este principalul fișier ETS care este livrat cu PowerShell Aveți grijă să nu modificați acel fișier în niciun fel (îl veți sparge), dar nu ezitați să-l utilizați ca șablon de copiere și inserare pentru propriile extensii Ne vom concentra pe adăugarea a două extensii la MOL Obiect Systemlnfo care este produs de funcția noastră Get-MOLSystemlnfo, care se află în fișierul nostru MOLTools psml Nu va trebui să modificăm deloc scriptul tiiat: crearea și încărcarea XML-ului ETS necesar va face tot ce avem nevoie Vom începe cu șablonul simplu din lista , pe care îl vom salva ca C:\MOLTools pslxml Salvarea fișierului în C:\ ne permite să ne jucăm cu el mai ușor; s-ar putea să fie nevoie să-l încărcăm din nou și din nou pentru a-l face corect, așa că vrem să facem accesul ușor Îl vom muta în locația sa finală când vom termina testarea Observați că extensia numelui de fișier este pslxml; este diferit de un fișier de vizualizare, care ar trebui să folosească format pslxml Extensiile noastre de tip vor locui în etichetele XML și Vom acoperi doar extensiile ScriptProperty și ScriptMethod în acest capitol, deoarece acestea sunt cele pe care le veți folosi cel mai mult Probabil că nu veți folosi prea mult AliasProperty atunci când vă extindeți propriile obiecte (la urma urmei, deoarece creați obiectul de la zero, puteți denumi proprietățile cum doriți în primul rând) Dar puteți examina fișierul Types psIxml furnizat de PowerShell pentru a vedea exemple de alte extensii Privind la ieșirea normală a lui Get-MOLSystemlnfo, vedem ceva de genul acesta: PS C:\> Get-MOLSystemlnfo -ComputerName localhost | Format-list * Manufacturer OSVersion BlOSSerial СотриterName SPVersion Model Manufacturer OSVersion BlOSSerial СотриterName SPVersion ModelParallels Software International Inc Parallels-D A C АВ E AF C D FC DC localhost Platformă virtuală Parallels Numărul de serie al BIOS-ului este foarte lung, cel puțin pentru acest computer Am dori o versiune a acestuia care să omite toate spațiile, pentru a crea un număr de serie mai scurt și mai concis Următoarea listă arată ce vom adăuga la MOLTools pslxmL M L Systemlnfo NormalizedBIOSSerial $this bioserial -replace ' ' Există câteva specifice de observat în acest sens: Eticheta trebuie să includă numele complet al tipului de obiect pe care vrem să îl extindem Creăm un singur bloc pentru un anumit tip de obiect Toate extensiile matrițelor pentru acel tip intră în blocul Veți vedea la ce ne referim atunci când adăugăm die următoarea extensie la tipul diis din este numele noii extensii ScriptProperty Codul de definire va rula când proprietatea este citită În cadrul blocului diis, die special $această variabilă se referă la obiectul însuși, permițându-ne să accesăm proprietățile și mediodele sale mai vechi În acest exemplu, folosim operatorul -replace din PowerShell pentru a înlocui spațiile cu un șir gol În funcție de computerul pe care îl întrebați, este posibil să nu obțineți un număr de serie BIOS care necesită normalizare De fapt, s-ar putea să nu primești deloc o valoare! Doar așa se comportă WMI Dar BIOS-ul pentru acest computer de testare a oferit o oportunitate rezonabilă de predare, așa că l-am rulat Pentru că MOL-ul nostru Obiectul Systemlnfo reprezintă un computer, dorim să oferim o modalitate rapidă de a ping computer prin intermediul rețelei Deoarece diat accesează resurse externe, o vom implementa ca ScriptMethod numit CanPingO Următoarea listă arată fișierul nostru revizuit C:\MOLTools pslxml MOL Systemlnfo „ScriptProperty” $this bioserial -replace ' ','' și , la fel ca ScriptProperty, deoarece aceste două extensii modifică fiecare același MOL Obiectul Systemlnfo Observați că, la fel ca și în cazul ScriptProperty pe care l-am creat, am putut folosi variabila $this pentru a ne referi la obiectul real Asta ne-a oferit acces la proprietatea ComputerName, care este locul în care am direcționat ping-ul Mai întâi, să rulăm comanda noastră Get-MOLSystemlnfo și să vedem ce fel de obiect produce Acesta va fi „înainte” în testul nostru „înainte și după”: PS C:\> Get-MOLSystemlnfo -ComputerName localhost | Obțineți-membru TipNume: Nume MOL Systemlnfo MemberType Definiție Egal Metodă bool Egal (System Object obj) GetHashCode Metodă int GetHashCode() GetType Metodă tastați GetType() ToString Metodă șir ToString() BlOSSerial NoteProperty System String BIOSSerial=Parallels-D A СотриterName NoteProperty System String ComputerName=localhost Producător NoteProperty System String Manufacturer=Paralleis Software Model NoteProperty System String Model=Parallels Virtual Platformă OSVersion NoteProperty System String OSVersion= SPVersion NoteProperty System UIntl SPVersion= Acum vom folosi Update-TypeData pentru a încărca fișierul XML ETS în memorie Vom folosi parametrul -PrependPath, astfel încât noile noastre date ETS să intre în memorie înainte de orice PowerShell a încărcat deja Consultați ajutorul comenzii pentru informații despre cealaltă opțiune, -AppendPath PS C:\> Update-TypeData -PrependPath \MOLTools pslxml Ca și în cazul majorității lucrurilor din PowerShell, nicio veste nu este o veste bună Niciun mesaj de eroare înseamnă că XML-ul nostru a fost analizat corect și a fost încărcat în shell Să vedem cum arată acum rezultatul comenzii noastre: PS C:\> Get-MOLSystemlnfo -ComputerName localhost | Obțineți-membru MemberType Definition MemberType Definition Name Equals GetHashCode GetType ToString BlOSSerial СотриterName Manufacturer Model OSVersion Name Equals GetHashCode GetType ToString BlOSSerial СотриterName Manufacturer Model OSVersionTypeName: MOL Systemlnfo Metoda bool Equals(System Object obj) Metoda int GetHashCode() metodă GetType() metodă ToString() NoteProperty System String BIOSSerial=Paralele- NoteProperty System String ComputerName=localhost NoteProperty System String Manufacturer=Paralel NoteProperty System String Model=Parallels Virtu NoteProperty System String SVersion= SPVersion NoteProperty System UIntl SPVersion= CanPing ScriptMethod System Object CanPingO; NormalizedBIOSSerial ScriptProperty System Object NormalizedBIOSSerial Au fost adăugate cele două extensii ale noastre! Să încercăm mai întâi ScriptProperty: PS C:\> Get-MOLSystemlnfo -ComputerName localhost | >> Select-Object -Property ComputerName,OSVersion,NormalizedBIOSSerial | >> Format-Tabel -AutoSize ComputerName OSVersion NormalizedBIOSSerial localhost Parallels-D A C ABE AFC D FCDC Perfect! Exact asta ne-am dorit în numărul de serie al matriței Acum să încercăm ScriptMethod Pentru diis, vom obține doar un obiect și îl vom salva într-o variabilă, astfel încât să putem testa cu ușurință metoda morții: PS C:\> $obj = Get-MOLSystemlnfo -ComputerName localhost PS C:\> $obj CanPing() Adevărat Perfect! Acum să vedem cum am putea folosi asta cu mai multe computere, pentru a filtra acele tiiat care nu răspund la un ping: PS C:\> Get-MOLSystemlnfo -ComputerName localhost,NOTONLINE | >> Where-Object -FilterScript { $ CanPingO } ComputerNa Mfgr Model OSVersion SP pe mine localhost Parallels Software Parallels Virtual AVERTISMENT: NOTONLINE a eșuat Perfect! Deși ei bine, să ne gândim la asta Get-MOLSystemlnfo în sine se bazează pe conectivitate la rețea, nu? Deci, un fel de înseamnă că oricine la care se poate conecta va răspunde și la un ping, nu? Ei bine, nu neapărat Un computer poate răspunde la utilizarea WMI de către Get-MOLSystemlnfo, dar are totuși un firewall local care blochează porturile ICMP utilizate de ping Deci încă efectuăm o verificare utilă Cel puțin, este un exemplu simplu de creare a unui ScriptMethod! Acum să mutăm MOLTools pslxml în folderul tiie folosit de modulul MOLTools: PS C:\> mutați \MOLTools pslxml C:\Users\donjones\Documents\WindowsPowerShel l\Modules\MOLTools Trebuie să avem o sarcină de extensie de tip tiie în același timp și restul de încărcări ale modulelor Am putea folosi New-ModuleManif est pentru a crea manifestul necesar, așa cum am făcut în capitolul despre crearea unei vizualizări de format personalizate Dar avem deja un manifest, așa că de ce să nu-l modificăm? Următoarea listă arată manifestarea MOLTools psdl modificată , cu singura noastră modificare evidențiată cu caractere aldine # Manifestul modulului pentru modulul „MOLTools” # Generat de: Don & Jeff # Generat pe: / / # @{ Modulul script sau fișierul modulului binar asociat cu acest manifest RootModule = ' \MOLTools psml' Numărul versiunii acestui modul ModuleVersion = „ ” ID folosit pentru a identifica în mod unic acest modul GUID = „ b d -c - - a - f b c a” Autorul acestui modul Autor = „Don & Jeff” Compania sau furnizorul acestui modul CompanyName = „Luna de prânz” Declarație de copyright pentru acest modul Drepturi de autor = '(c) Don Jones și Jeffery Hicks' Descrierea funcționalității oferite de acest modul Descriere = „Modul eșantion pentru luna de prânz” Versiunea minimă a motorului Windows PowerShell cerută de acest modul PowerShellVersion = „ ” Numele gazdei Windows PowerShell cerut de acest modul PowerShellHostName = '' Versiunea minimă a gazdei Windows PowerShell cerută de acest modul PowerShellHostVersion = '' Versiunea minimă a NET Framework cerută de acest modul DotNetFrameworkVersion = '' Versiunea minimă a Common Language Runtime (CLR) cerută de aceasta modul CLRVersion = '' Arhitectura procesorului (Niciun, X , Amd ) cerută de acest modul ProcessorArchitecture = '' Module care trebuie importate în mediul global înainte de importul acestui modul RequiredModules = @() Ansambluri care trebuie încărcate înainte de a importa acest modul RequiredAssemblyes = @() Fișiere script ( psl) care sunt rulate în mediul apelantului înainte de importul acestui modul ScriptsToProcess = @() Туре fișiere ( pslxml) de încărcat la importul acestui modul TypesToProcess = "MOLTools pslxml" Formatați fișierele ( pslxml) care urmează să fie încărcate la importul acestui modul FormatsToProcess = 'MOLTools format pslxml' Module de importat ca module imbricate ale modulului specificat în RootModule/ ModuleToProcess NedModules = @() Funcții de exportat din acest modul FunctionsToExport = Cmdlet-uri de exportat din acest modul CmdletsToExport = ' * ' Variabile de exportat din acest modul VariablesToExport = '*' Aliasuri de exportat din acest modul AliasesToExport = Comenzi de export din acest modul ca fluxuri de lucru ExportAsWorkflow = @() Lista tuturor modulelor ambalate cu acest modul ModuleList = @() Lista tuturor fișierelor împachetate cu acest modul FileList = @() Date private de transmis la modulul specificat în RootModule/ModuleToProcess PrivateData = '' Helplnfo URI al acestui modul HelpInfoURI = '' Prefix implicit pentru comenzile exportate din acest modul Ignorați valoarea implicită prefix folosind Import-Module -Prefix DefaultCommandPrefix = '' } Odată cu această modificare, ne putem importa modulul și acesta va încărca comenzile, vizualizarea formatului și extensia noastră de tip, toate odată Revizuiți modul de funcții avansate pe care l-ați scris pentru Laboratorul A în capitolele până la ale acestei cărți Creați o extensie de tip personalizat pentru ieșirea obiectului matriță prin funcția diat Extensia dvs de tip ar trebui să fie o ScriptMethod numită CanPing (), după cum este descris în capitolul al doilea Salvați fișierul cu extensia de tip ca PSHTools pslxml Modificați manifestul modulului PSHTools pentru a încărca PSHTools pslxml și testați modulul revizuit pentru a vă asigura că metiiodul CanPing () funcționează Fluxurile de lucru sunt o nouă caracteristică importantă a PowerShell v Sunt o tehnologie incredibil de bogată și complexă, pe care nu o putem acoperi cuprinzător în acest capitol; chiar merită propria lor carte Dar acestea sunt un tip de instrument pe care îl puteți crea și pe care îl puteți folosi foarte bine, așa că am dorit să includem acest capitol ca o introducere la ele Fluxurile de lucru sunt un tip de comandă PowerShell, la fel cum cmdleturile și funcțiile sunt tipuri de comenzi Una dintre cele mai ușoare moduri de a înțelege fluxurile de lucru este să le contrastezi cu cel mai apropiat văr: funcțiile Funcțiile sunt declarate cu cuvântul cheie function, așa cum ați văzut de mai multe ori în capitolele anterioare; fluxurile de lucru sunt declarate cu cuvântul cheie tiie workflow Funcțiile sunt executate chiar de PowerShell; fluxurile de lucru sunt traduse în Windows Workflow Foundation (WF) din NET Framework și executate de WF extern la PowerShell Atât funcțiile, cât și fluxurile de lucru execută un anumit set de comenzi într-o anumită secvență, dar fluxurile de lucru - de la WF - includ înregistrarea detaliată și urmărirea fiecăreia și includ posibilitatea de a reîncerca pașii care nu eșuează din cauza, de exemplu, a unui sughiț intermitent al rețelei sau a altor probleme chestiune tranzitorie Funcțiile fac o tiiing la un moment dat; fluxurile de lucru pot face un singur lucru de mai multe ori—multitasking paralel Funcțiile pornesc, rulează și se termină; un flux de lucru poate întrerupe, opri și reporni Dacă opriți computerul în mijlocul unei funcții, funcția se pierde; dacă faceți acest lucru în timp ce un flux de lucru rulează, fluxul de lucru poate fi recuperat și reluat automat Funcție sau flux de lucru Executed by PowerShell Logging and retry attempts through compli- cated coding Single-action Processing Runs to completion Data loss possible during network problems Full language set and syntax Runs cmdlets Executed by PowerShell Logging and retry attempts through compli- cated coding Single-action Processing Runs to completion Data loss possible during network problems Full language set and syntax Runs cmdlets Executed by workflow engine Logging and retry attempts part of the workflow engine Supports parallelism Can run, pause, and restart Data can persist during network problems Limited language set and syntax Runs activities Executed by workflow engine Logging and retry attempts part of the workflow engine Supports parallelism Can run, pause, and restart Data can persist during network problems Limited language set and syntax Runs activities Tabelul ilustrează unele dintre diferențele dintre o funcție și un flux de lucru Fluxurile de lucru sunt încorporate în shell prin rularea Import-Module PSWorkflow; acel modul extinde PowerShell pentru a înțelege fluxurile de lucru și pentru a le executa corect Fluxurile de lucru sunt expuse ca comenzi, ceea ce înseamnă că le executați la fel ca și comenzile De exemplu, dacă ați creat un flux de lucru numit Do-Something, ați rula doar Do-Something pentru a-l executa sau executați Do-Something -AsJob pentru a-l rula în sistemul de lucru de bază al PowerShell Executarea unui flux de lucru ca ajob este mișto, deoarece puteți utiliza apoi cmdlet-urile standard -Job (cum ar fi Get-Job și Receive-Job) pentru a gestiona diem Există, de asemenea, comenzi Suspend-Job și Resume-Job pentru a întrerupe și a relua un flux de lucru Doar folosind cuvântul cheie die workflow, oferiți comenzii fluxului de lucru un set destul de mare de parametri comuni încorporați Nu vom oferi o listă extinsă, dar iată câteva dintre cele mai interesante (și puteți consulta documentația PowerShell pentru lista completă): -PSComputerName—O listă de computere pe care să execute fluxul de lucru - PSParameterCollection—O listă de tabele hash care specifică valori diferite ale parametrilor pentru fiecare computer țintă, permițând fluxului de lucru să aibă un comportament variabil pe bază de mașină -PSCredential—Acreditarea care trebuie utilizată pentru a executa fluxul de lucru flie -PSPersist—Forțați fluxul de lucru pentru a salva (punctul de control) datele și starea fluxului de lucru după executarea fiecărui pas (vă vom arăta cum puteți face și manual) Există, de asemenea, o varietate de parametri care vă permit să specificați opțiuni de conectivitate la distanță, cum ar fi -PSPort, -PSUseSSL, -PSSessionOption și așa mai departe; fliese corespund parametrilor numiti similar ai comenzilor de la distanță, cum ar fi Invoke-Command și New-PSSession Valorile transmise parametrilor fliese sunt accesibile ca valori în fluxul de lucru De exemplu, un flux de lucru poate accesa $PSComputerName pentru a obține numele computerului cu care se execută o anumită instanță a fluxului de lucru chiar atunci Fluxul de lucru este construit în jurul conceptului de activități Fiecare comandă PowerShell pe care o executați într-un flux de lucru este o activitate unică, de sine stătătoare Cel mai important lucru cu care trebuie să vă obișnuiți în fluxul de lucru este să executați fiecare comandă sau activitate pe cont propriu Deoarece un flux de lucru poate fi întrerupt și reluat ulterior, fiecare comandă trebuie să presupună că rulează într-un mediu complet nou, complet nou Variabilele create de o comandă nu pot fi folosite de următoarea comandă, ceea ce poate deveni puțin ciudat Workflow acceptă un bloc InlineScript, care va executa toate comenzile din flie block într-o singură sesiune PowerShell Tot ce se află în blocul este un script de sine stătător Acum, tiiis nu înseamnă că tiiat variabilele nu funcționează deloc; tiiat ar fi destul de inutil De exemplu, luați în considerare tiie script în următoarea listă (am inclus tiiis ca o listă numerotată, astfel încât să îl puteți rula singur în tiie PowerShell ISE, dacă doriți) Import-Module PSWorkflow workflow Test-Workflow { $a = $a $a+ + $a $b = $a + $b Test-flux de lucru Rulați tiiis și ar trebui să vedeți ieșirea , și , cu fiecare număr pe propria linie Acesta este rezultatul așteptat și, văzând acest lucru, vă va ajuta să verificați dacă fluxul de lucru funcționează pe sistemul dvs Acum încercați exemplul din această listă Import-Module PSWorkflow workflow Test-Workflow { $obj = New-Object -TypeName PSObject $obj | Add-Member -MemberType NoteProperty -Name ExampleProperty -Valoare „Bună ziua!” $obj | Obțineți-membru } Test-flux de lucru Acest lucru nu produce rezultatele dorite, în sensul că obiectul din $obj nu va avea o proprietate ExampleProperty care să conțină „Bună ziua” Asta pentru că Add-Member nins în propriul spațiu, iar modificarea sa la $obj nu persistă în a treia comandă din fluxul de lucru Pentru ca acest lucru să funcționeze, am putea împacheta întregul set de comenzi ca un InlineScript, forțându-le să se execute toate în același timp, într-o singură instanță PowerShell Următoarea listă arată acest exemplu Import-Module PSWorkflow workflow Test-Workflow { InlineScript { $obj = New-Object -TypeName PSObject $obj | Add-Member -MemberType NoteProperty -Nume ExampleProperty -Valoare „Bună ziua!” $obj | Obțineți-membru } } Test-flux de lucru Încercați fiecare dintre aceste trei exemple și comparați rezultatele Fluxurile de lucru necesită puțin timp pentru a vă obișnui, iar aceste exemple simple vă vor ajuta să începeți să înțelegeți diferențele cheie ale fluxului de lucru Starea unui flux de lucru constă în ieșirea curentă, sarcina pe care o execută în prezent și alte informații Este important să ajuți fluxul de lucru să mențină starea lui, mai ales când lansați o comandă de lungă durată care ar putea fi executată Pentru a face acest lucru, executați comanda Checkpoint-Workflow (sau activitatea de flux de lucru Persist) Puteți forța ca fliis să se întâmple după ce fiecare comandă este executată, rulând fluxul de lucru flie cu comutatorul -PSPersist Un flux de lucru se poate suspenda dacă rulați Suspend-Workflow în cadrul fluxului de lucru flie Puteți face acest lucru, de exemplu, dacă sunteți pe cale să rulați o comandă cu volum mare de lucru care poate fi executată numai în timpul unei ferestre de întreținere Înainte de a rula comanda, verificați ora și, dacă nu vă aflați în fereastra flie, suspendați fluxul de lucru flie Cineva ar trebui să reia manual fluxul de lucru flie (sau să îl programeze în Task Scheduler) rulând Resume-Job și furnizând ID-ul necesar jobului Fluxurile de lucru sunt proiectate de la sol pentru a fi de la distanță, motiv pentru care toate comenzile de flux de lucru primesc automat un parametru -PSComputerName Dacă rulați un flux de lucru cu unul sau mai multe nume de computer, PowerShell se conectează la computere de la distanță prin intermediul Remoting (care trebuie să fie activat) și face ca acele computere să ruleze fluxul de lucru folosind resursele locale Aceasta înseamnă că computerele de la distanță trebuie să ruleze și Power Shell Dar următoarele comenzi de bază PowerShell rulează întotdeauna local pe mașina de matriță unde a fost inițiat fluxul de lucru: Adăugați-Membru Comparare-Obiect ConvertFrom-Csv, ConvertFtom-Json, ConvertFrom-StringData Conversie-Cale ConvertTo-Csv, ConvertTo-Html, ConvertTo-Xml PentruFiecare-Obiect Get-Host Obțineți-membru Ia-aleatoriu Ia-unic Grup-Obiect Măsură-Obiect Măsura-Comandă New-PSSessionOption, Nou-PSTransportOpt ion Nou-TimeSpan Out-Default, Out-Host, Out-Null, Out-String Selectare-Obiect Lista de actualizare Scriere-Depanare, Scriere-Eroare, Write-Host, Write-Output, Write-Progress, Write-Verbose, Write-Warning Sortare-Obiect Unde-Obiect Acestea sunt rulate local în principal din motive de performanță; dacă aveți nevoie de unul dintre fliese pentru a rula pe un computer la distanță vizat, includeți-l într-un bloc InlineScript {} Fluxul de lucru Windows este conceput pentru a executa sarcini în paralel, iar PowerShell expune această capacitate printr-o construcție de scripting ForEach modificată și o nouă construcție Parallel Ele funcționează puțin diferit Cu Parallel, comenzile flie din interiorul flie construct pot rula în orice ordine În blocul flie Parallel, puteți utiliza cuvântul cheie flie Sequence pentru a înconjura un set de comenzi care trebuie executate în ordine; Tiiat lot de comenzi poate începe executarea în orice moment, de exemplu: Test flux de lucru-Flux de lucru { „Acesta va rula primul” paralel { „Comanda ” „Comanda ” secvență { "Comanda A" "Comanda B" Ieșirea de aici ar putea fi Comanda Comandamentul A Comanda Â Comanda Comanda В va veni întotdeauna după Comanda A, dar Comanda A poate veni prima, a doua sau ultima — nu există nicio garanție De fapt, comenzile se execută în același timp, ceea ce înseamnă Comanda , Comanda , iar secvența poate începe o dată, ceea ce face ca rezultatul să fie oarecum nedeterminist Acest lucru este util atunci când aveți mai multe sarcini de finalizat, nu vă pasă de ordinea în care acestea rulează și doriți ca acestea să se termine cât mai repede posibil Paralelizarea ForEach este oarecum diferită: Test flux de lucru-Flux de lucru { Foreach -paralel ($computer în $computerName) { Do-Something -computerName Școmputer } } Aici, WF poate lansa simultan mai multe comenzi Do-Something, fiecare vizand un computer diferit Execuția ar trebui să fie aproximativ în orice ordine în care computerele sunt stocate în $ComputerName, deși din cauza variațiilor de execuție ordinea rezultatelor este nedeterministă Este important să înțelegeți că întregul conținut al fluxului de lucru este tradus în limba proprie a WF, care înțelege doar activitățile Cu excepția câtorva comenzi pe care le vom enumera la sfârșitul acestui capitol, Microsoft a furnizat activități WF care să corespundă majorității cmdlet-urilor PowerShell de bază Aceasta înseamnă că majoritatea comenzilor încorporate ale PowerShell – cele disponibile înainte ca orice module să fie importate – funcționează perfect Nu este cazul modulelor suplimentare, desigur În plus, deoarece fiecare activitate de flux de lucru se execută într-un spațiu autonom, nici măcar nu puteți utiliza Import-Module singur într-un flux de lucru Practic ai importa un modul, dar acesta va dispărea în momentul în care ai încercat să rulezi oricare dintre comenzile modulului Soluția este să ne gândim la un flux de lucru ca la un mecanism de coordonare a sarcinilor la nivel înalt Este posibil să aveți un număr de blocuri InlineScript {} într-un flux de lucru, deoarece conținutul acestor blocuri se execută ca o singură unitate, într-o singură sesiune PowerShell Într-un InlineScript {}, puteți importa un modul și puteți rula comenzile acestuia Fiecare bloc InlineScript {} pe care îl includeți rulează independent, așa că gândiți-vă la fiecare ca un fișier de tip script de sine stătător: Fiecare ar trebui să efectueze toate sarcinile de configurare necesare pentru ca acesta să ruleze cu succes Veți vedea un exemplu de abordare în acest capitol Ca exemplu de scenariu, vom pretinde că avem o nouă actualizare internă a aplicației corporative care trebuie implementată Ne-am ocupat deja să implementăm executabilele necesare pe computerele noastre client, dar dezvoltatorii au neglijat să facă câteva modificări critice de configurare ca parte a programului de instalare Depinde de noi să facem modificări Trebuie să facem următoarele: Adăugați o cheie de registry HKEY LOCAL MACHINE\SOFTWARE\Company\LOBApp\Settings, adăugând setarea Rebuild cu o valoare de (zero) Înregistrați un nou punct final PowerShell Remoting (sau configurație de sesiune) numit LOBApp Tiiere este deja un fișier local de configurare a sesiunii stocat pe fiecare computer care definește capacitățile acestui punct final; fișierul ar trebui să fie în C:\CcirpAppsXj О IJAp p\J OlJApp psc Setați serviciul numit LOBApp să pornească automat și asigurați-vă că serviciul este pornit Rulați Set-LOBRebuildMode -Mode —comanda tiie este localizată într-un modul numit LOBAppTools, care este deja implementat pe computerele client Niciuna dintre acestea nu trebuie făcută într-o anumită ordine Rețineți că conținutul fluxului nostru de lucru este destinat să fie de la distanță, așa că putem presupune că fiecare lucru pe care îl facem rulează local, iar acestea vor fi implementate pe computerele de la distanță și executate acolo Deoarece folosim lucruri inventate în acest exemplu, nu veți putea urmări Iată fluxul de lucru pe care l-am putea scrie pentru a realiza scenariul nostru exemplu flux de lucru Set-LOBAppConfiguration { paralel { InlineScript { Nou-Articol -Cale HKLM:\SOFTWARE\Company\LOBApp\Settings New-ItemProperty -Cale HKLM:\SOFTWARE\Company\LOBApp\Settings -Nume Reconstruire -Valoarea } InlineScript { Set-Service -Nume LOBApp -StartupType Pornire automată-Service -Nume LOBApp } InlineScript { Register-PSSessionConfiguration -Calea C:\CorpApps\LOBApp\LOBApp pscl -Nume LOBАрр } InlineScript { Import-Module LOBAppTools Set-LOBRebuildMode -Mod } } } Puteți vedea că am urmat strategia generală de a împărți fiecare sarcină distinctă în propriul bloc InlineScript {}, permițând fiecăruia să se execute independent Fiecare poate presupune că accesează resurse locale, deoarece conținutul fluxului de lucru va fi retras la orice mașină vizată Am rula diis astfel: PS C:\> Set-LOBAppConfiguration -PSComputerName unu, doi, trei Acest lucru ar rula fluxul de lucru pe computerele numite UNU, DOI și TREI Fluxurile de lucru par atât de asemănătoare cu funcțiile încât poate fi tentant să presupunem că sunt doar un fel de funcție elegant În multe feluri, este sigur să știi în mod sigur, care este unul dintre aspectele lor cele mai atrăgătoare: dacă știi deja multe despre funcții, poți muta cunoștințele direct în fluxurile de lucru cu foarte puține învățăminte suplimentare Acestea fiind spuse, sunt câteva diferențe majore Mai exact, fluxurile de lucru diferă de funcții în următoarele moduri: Nu puteți utiliza blocurile de script BEGIN, PROCESS și END pe care le folosim în funcțiile noastre avansate Nu puteți utiliza subexpresii, cum ar fi $myvar = "$ ($service name) " Nu puteți accesa variabile calificate pentru unitate, cum ar fi $env: computername; utilizați în schimb Get-Content ENV: ComputerName Numele variabilelor pot conține numai litere, cifre, - și Nu poți executa metiiode de obiecte Acest lucru este complicat, dar este un motiv bun: pentru a executa o procedură, aveți nevoie de un obiect viu Dacă fluxul de lucru se reia de la întrerupere, totuși, tot ce veți avea este un obiect persistent, deserializat, care nu are metode Dacă creați un obiect într-un bloc InlineScript, atunci puteți executa metodele acestuia în acel bloc, deoarece blocul asigură că toate comenzile se execută împreună Nu puteți atribui valori proprietăților obiectului - din nou, acest lucru presupune un obiect activ, pe care nu îl veți avea neapărat Nu puteți să punctați scripturile sursă sau să utilizați operatorul de invocare (&) Validarea avansată a parametrilor funcției (cum ar fi atributele obligatorii și alte atribute pe care le-am folosit) nu sunt acceptate pe fluxurile de lucru, care sunt conținute în alte fluxuri de lucru Din punct de vedere tehnic, nu sunt permise deloc, dar PowerShell o falsifică pentru fluxul de lucru exterior Parametrii de poziție nu sunt permisi pentru comenzile dintr-un flux de lucru Acest lucru vă obligă să urmați ceea ce ar trebui să faceți oricum și să enumerați numele parametrului pentru fiecare parametru pe care îl utilizați Aceasta înseamnă Dir C: \ nu va funcționa, dar Dir - Calea C: \ va Vechea instrucțiune de tratare a erorilor Trap nu este acceptată Utilizați Încercați Prinde În sfârșit, în schimb Declarația Switch nu funcționează la fel într-un flux de lucru; vă recomandăm să nu-l utilizați deloc într-un flux de lucru Fluxurile de lucru nu pot folosi ajutorul bazat pe comentarii Dacă doriți să includeți ajutor pentru o comandă de flux de lucru, trebuie să creați un fișier XML extern în format MAML corespunzător; nu vom acoperi fliat în fliis book Într-un flux de lucru, nu puteți modifica valoarea de zbor a unei variabile care a fost deja definită într-un domeniu părinte Într-o funcție PowerShell normală, procedând astfel, se creează o nouă variabilă locală cu același nume; în fluxul de lucru, primești o eroare PowerShell adaugă un nou identificator $workf cu sfera redusă pentru a oferi acces la sfera de aplicare a fluxului de lucru din orice sfera secundară De exemplu, $workf lowimyvar va oferi acces la variabila flie $myvar definită în domeniul fluxului de lucru flie Această sintaxă este obligatorie pentru orice domeniu copil; Dacă unul dintre ei ar încerca să modifice $myvar wifliout specificând $workf low:myvar, ar primi o eroare Aceasta nu este o listă cuprinzătoare de operațiuni legale care sunt legale într-o funcție, dar nu într-un flux de lucru, dar lista de muște acoperă fiecare lucru legat de funcții pe care v-am arătat în cartea fliis (inclusiv chestii din capitolele următoare) Cele mai multe dintre restricțiile de lucru provin din faptul că un flux de lucru este în cele din urmă tradus într-un limbaj extern utilizabil de WF, ceea ce înseamnă că un flux de lucru nu poate conține niciun fel pentru care fluierul nu este echivalent WF Există, de asemenea, câteva comenzi native PowerShell fliat care nu pot fi utilizate în cadrul unui flux de lucru, în principal pentru că, în majoritatea cazurilor, fliey nu are sens: Get-Alias, Export-Alias, Import-Alias, New-Alias, Set-Alias Actualizare-FormatData Adăugați-Istoric, Șterge-Istoric, Obține-Istoric, Invocare-Istoric Nou-PSDrive, Eliminați-PSDrive Set-StrictMode Start-Transcript, Stop-Transcript Remove-TypeData, Update-TypeData Clear-Variable, Get-Variable, New-Variable Deoarece fluxurile de lucru sunt în mod necesar complexe și pentru că v-am oferit doar o prezentare generală a fliem în capitolul fliem, nu vă vom cere să finalizați un laborator care implică fluxuri de lucru Dacă doriți să aflați mai multe despre fluxurile de lucru PowerShell, obțineți o versiune de PowerShell aprofundată: un ghid al administratorului de Donjones, Richard Siddaway și Jeffery Hicks Veți găsi un capitol despre funcția fliis împreună cu multe exemple O parte din ceea ce face ca PowerShell să fie atât de unic și puternic este conducta sa orientată pe obiecte Când scrieți instrumente, este deosebit de important să înțelegeți cum funcționează conducta matriței, cum pot funcționa instrumentele dvs în el și, cel mai important, să știți cum să depanați ce se întâmplă în conducta matriței Asta va acoperi acest capitol Ori de câte ori transmiteți o comandă către anodier - să spunem, Get-Service | Unde Status -eq „În rulare” | Sortare Nume | Servicii de export-CSV csv—ieșirea este preluată de la o comandă și transmisă pentru a muri în continuare Tiiere nu este o modalitate magică de transmitere a ieșirii: comenzile PowerShell pot accepta intrare numai prin intermediul parametrilor lor În acest exemplu, PowerShell trebuie să ia rezultatul Get-Service și să descopere ce parametru al Where-Obj ect poate accepta acele obiecte După Where-Obj ect nins, ieșirea sa intră în conductă, iar PowerShell trebuie să-și dea seama ce parametru al Sort-Obj ect poate accepta diat Acest proces de determinare se numește legarea parametrilor conductei PowerShell are două moduri pentru legarea parametrilor conductei Primul mod, sau Planul A, așa cum îl numim, se numește ByValue În modul diis, PowerShell caută să vadă dacă comanda de primire are un parametru care poate accepta tipul exact de obiect care a fost introdus în conducta prin comanda de trimitere De exemplu, în comanda Get-Service -Name BITS | Stop-Service, Get-Service este comanda de trimitere și produce obiecte de tipul ServiceController Puteți verifica acest lucru rulând Get-Service -Name BITS | Get-Member și uită-te la prima linie a ieșire Stop-Service este comanda de primire, iar parametrul său -InputObject este capabil să accepte obiecte de tip ServiceController, din pipeline, ByValue Fișierul de ajutor pentru Stop-Service confirmă capacitatea diis (rulați Help Stop-Service -full și vedeți singur) Deci obiectele de serviciu sunt legate de parametrul -InputObject Când comanda de primire a matriței nu are un parametru capabil să accepte tipul de obiect al matriței în conducta ByValue, PowerShell trece la Planul B, care se numește ByPropertyName În modul diis, tipul obiectului nu contează Radier, Power Shell realizează un inventar al parametrilor comenzii de primire a matriței, care sunt programați pentru a accepta intrarea conductei ByPropertyName (puteți citi ajutor complet pentru o comandă de inventariere a acelor parametri pe cont propriu) PowerShell se uită la obiectele din conducta și se potrivește cu orice proprietăți care se întâmplă să fie scrise la fel ca parametrii de primire De exemplu, în comanda Get-Service | Stop-Process -whatlf (pe care sunteți binevenit să îl rulați, dacă doriți să vedeți ce se întâmplă), știm că comanda de trimitere produce obiecte de tip ServiceController Comanda de primire nu are parametri capabili să accepte acest tip de obiect, așa că Planul A, ByValue, este exclus Stop-Process are doi parametri capabili să accepte intrarea conductei ByPropertyName, care este Planul B Acei parametri sunt -Id și -Name Deci, PowerShell va prelua proprietatea ID a obiectelor pipeline și va alimenta valorile acestora la parametrul -Id De asemenea, va lua proprietatea Name a obiectelor pipeline și va alimenta acele valori la parametrul -Name După cum se dovedește, obiectele ServiceController nu au o proprietate ID, așa că va fi doar parametrul -Name care primește valorile proprietăților Name ale obiectelor Acest proces de legare a parametrilor conductei este PowerShell Sperăm că, dacă sunteți implicat în fabricarea de instrumente, sunteți deja familiarizat cu procesul de bază Dacă nu, vă sugerăm să citiți „Windows PowerShell într-o lună de prânz”, care acoperă procesul mai în profunzime A fi capabil să vă gândiți la procesul din cap și să preziceți ce va face PowerShell cu orice comandă dată este o abilitate importantă, deoarece vă permite să vă creați propriile combinații de comenzi Dar ceea ce poate fi și mai bine – în special pentru depanare – este să vezi cum se întâmplă Amintiți-vă, majoritatea erorilor sunt rezultatul unei presupuneri sau predicții proaste Dacă aveți o așteptare cu privire la modul în care PowerShell va lega două comenzi împreună, atunci puteți utiliza ceea ce vă vom arăta pentru a confirma sau corecta această așteptare Cmdlet-ul Trace-Command încorporat al PowerShell oferă o serie de capabilități utile de diagnosticare și depanare, dar în acest capitol ne vom concentra pe capacitatea sa de a dezvălui ce face PowerShell cu legarea parametrilor conductei Ca exemplu, să luăm comanda tiiis: Import-CSV computers csv | Get-WmiObject -class Win BIOS Presupunerea noastră este că Computers csv arată astfel: Numele calculatorului SERVER-R DC GAZDĂ LOCALĂ CLIENTA Rularea comenzii de import de la sine are ca rezultat următoarele: PS C:\> import-csv \computers csv numele calculatorului SERVER-R DC GAZDĂ LOCALĂ CLIENTA Comanda a produs patru obiecte, fiecare având o proprietate Сотри terName Ne așteptăm ca acele proprietăți să se lege, ByPropertyName, de parametrul -ComputerName al Get-WmiObj ect În acest mod, ne așteptăm să recupereze clasa Win BIOS de la fiecare dintre aceste patru computere Nu vă obosiți să rulați această comandă încă Scopul nostru nu este să încercăm, ci mai degrabă să anticipăm ce va face și apoi să testăm acea predicție folosind un instrument de depanare Formatul de bază de utilizare pentru Trace-Command este următorul: Trace-Command -Name Parameterbinding -PSHost -Expression { } În blocul expresiei {}, puneți orice comandă doriți să testați Acea comandă se va executa, așa că dacă face ceva periculos, fiți precaut Pe lângă executarea comenzii, shell-ul va captura și afișa câteva elemente interne despre ceea ce face Deci vom rula următoarele: PS C:\> Trace-Command -name ParameterBinding -PSHost -Expression { Import-C sv \computers csv | Get-WmiObject -Class Win BIOS } Vom lipi o parte din rezultatul urmăririi și vom oferi o explicație pentru ceea ce vedem: DEBUG: ParameterBinding Information: : BIND NAMED cmd line args [Import-Csv] DEBUG: ParameterBinding Information: : BIND POSITIONAL cmd line args [ Import-Csv] DEBUG: Informații privind legarea parametrilor: : BIND arg [ \computers csv] la parametru [Cale] Aceasta înseamnă că PowerShell leagă parametrii denumiți și de poziție Se ocupă de orice parametri pe care i-am introdus manual Aceștia sunt întotdeauna legați primii și suprascriu orice introdus în conducte care ar fi putut fi atașat acelor parametri Nu puteți vedea că calea noastră, \computers csv, este atașată la parametrul -Path: DEBUG: Informații privind legarea parametrilor: : colecția de legare Calea parametrului: tipul argumentului [String], tipul parametrului [System String[]], tipul colecției Array, tipul elementului [System String], fără coerceElementType DEBUG: ParameterBinding Information: : Crearea matricei cu tip de element [System String] și elemente DEBUG: ParameterBinding Information: : Tipul de argument String este nu IList, tratând acest lucru ca pe un scalar DEBUG: ParameterBinding Information: : Adăugarea elementului scalar al tastați String în poziția matricei DEBUG: Informații privind legarea parametrilor: : Se execută VALIDAREA metadate: [System Management Automation ValidateNotNullOrEmptyAttribute] DEBUG: ParameterBinding Informații: : BIND arg [System String[]] pentru a parametriza [Calea] SUCCES Parametrul -Path al Import-CSV necesită o matrice Deoarece am specificat o singură valoare, PowerShell creează o matrice și adaugă valoarea noastră unică la acea matrice Ultimul lucru pe care îl face este să valideze că parametrul -Path nu este nul și nu este gol, înainte de a declara legarea cu succes a parametrului -Path: DEBUG: Informații privind legarea parametrilor: : VERIFICAREA PARAMETRILOR OBLIGATORII pe cmdlet [Import-Csv] Shell-ul tocmai a verificat pentru a se asigura că au fost furnizați toți parametrii obligatorii ai Import-Csv Au fost sau am fi văzut mesaje de eroare Deci suntem gata să trecem la următoarea comandă: DEBUG: ParameterBinding Information: : BIND NAMED cmd line args [Get-WmiObj ect] DEBUG: Informații privind legarea parametrilor: : BIND arg [Win BI S] la parametru [Class] DEBUG: ParameterBinding Information: : COERCE arg to [System String] DEBUG: ParameterBinding Informații: : Parametru și arg tipează la fel, nu este nevoie de constrângere DEBUG: ParameterBinding Information: : BIND arg [Win BIOS] to param [Class] SUCCESSFUL DEBUG: ParameterBinding Information: : BIND POSITIONAL cmd line args [Get-WmiObj ect] DEBUG: Informații privind legarea parametrilor: : VERIFICAREA PARAMETRILOR OBLIGATORII pe cmdlet [Get-WmiObject] Toate acestea au fost pentru Get-WmiObject Nu, parametrii -Class vor un șir, ceea ce i-am dat, așa că PowerShell recunoaște că nu este necesară nicio conversie a tipului de date (coerciție) Am furnizat toți parametrii obligatorii, așa că suntem autorizați pentru decolare DEBUG: Informații ParameterBinding: : CALLING BeginProcessing DEBUG: Informații ParameterBinding: : CALLING BeginProcessing Aceste două linii indică faptul că începem să rulăm cmdleturile: DEBUG: ParameterBinding Information: : BIND PIPELINE obiect la parametri: [Get-WmiObject] DEBUG: ParameterBinding Information: : PIPELINE obiect TYPE = [System Management Automation PSCustomObj ect] Acesta este partea cheie a procesului Nu, PowerShell spune: „Bine, Import-Csv produce obiecte de tipul PSCustomObject Acestea sunt în curs, așa că trebuie să le legăm la următoarea comandă, care este Get-WmiObj ect ” DEBUG: ParameterBinding Information: : RESTAURARE conductă valorile originale ale parametrului DEBUG: ParameterBinding Information: : BIND PIPELINE obiect la parametri: [Out-Default] Aproape întotdeauna veți vedea Out-Default în codul de urmărire, deoarece este codificat, în culise, la sfârșitul fiecărei conducte Chiar dacă nu l-am scris în mod explicit, este acolo și PowerShell trebuie să se ocupe de el DEBUG: ParameterBinding Information: : PIPELINE obiect TYPE = [System Management Automation ErrorRecord] DEBUG: ParameterBinding Information: : RESTAURARE conductă valorile originale ale parametrului DEBUG: Informații privind legarea parametrilor: : Parametrul [InputObject] PIPELINE INPUT ValueFromPipeline FĂRĂ COERȚIE DEBUG: ParameterBinding Informații: : BIND arg [Obiectul de intrare nu poate fi legat de niciun parametru pentru comandă, fie pentru că comanda nu preia intrarea în conductă, fie intrarea și proprietățile sale nu se potrivesc cu niciunul dintre parametrii care preiau intrarea în conductă ] la parametrul [InputObj ect] Asta nu e bine Înseamnă că PowerShell nu a putut găsi niciun parametru al Get-WmiObj ect care ar putea accepta obiectele noastre pipeline, fie ByValue, fie ByPropertyName Comanda noastră eșuează O mare parte din restul rezultatului de urmărire este doar PowerShell care se ocupă de eroare și pregătește o înregistrare de eroare pentru afișajul nostru Deci, ce a mers prost? Aruncă o privire la ajutorul complet pentru Get-WmiObj ect Niciun parametru nu acceptă un obiect de tipul PSCustomObj ect, deci Planul A, ByValue, eșuează Asta îl lasă să încerce să atașeze proprietatea ComputerName la parametrul -ComputerName, care, din păcate, nu este programat, în acest caz, să accepte intrarea pipeline Deci comanda a eșuat Dacă am fi citit cu atenție ajutorul din timp, probabil am fi putut prezice asta! Să rulăm o a doua comandă prin proces — de data aceasta, una care ar trebui să funcționeze, astfel încât să puteți vedea cum arată o legare de succes Vom folosi o comandă similară, dar una al cărei parametru -computerName este conectat pentru intrarea în conductă: PS C:\> Trace-Command -name ParameterBinding -PSHost -Expression { Import-C sv \computers csv | Get-Service -Nume * } DEBUG: ParameterBinding Information: : BIND NAMED cmd line args [Import-Csv] DEBUG: ParameterBinding Information: : BIND POSITIONAL cmd line args [Import-Csv] DEBUG: Informații privind legarea parametrilor: : BIND arg [ \computers csv] la parametru [Cale] Încă o dată, am început prin a lega numele fișierului la parametrul -Path al Import-Csv: DEBUG: Informații privind legarea parametrilor: : colecția de legare Calea parametrului: tip argument [String], tip parametru [System String[]], tip colecție Array, tip element [System String], fără coerceElementType DEBUG: ParameterBinding Information: : Se creează matrice cu tip de element [System String] și elemente DEBUG: ParameterBinding Information: : Tipul de argument String este nu IList, tratând acest lucru ca pe un scalar DEBUG: ParameterBinding Information: : Adăugarea elementului scalar al tastați String în poziția matricei DEBUG: Informații privind legarea parametrilor: : Se execută VALIDAREA metadate: [System Management Automation ValidateNotNullOrEmptyAttribute] DEBUG: ParameterBinding Informații: : BIND arg [System String[]] pentru a parametriza [Calea] SUCCES DEBUG: Informații privind legarea parametrilor: : VERIFICAREA PARAMETRILOR OBLIGATORII pe cmdlet [Import-Csv] PowerShell a creat o matrice cu un singur articol, l-a validat și s-a asigurat că furnizăm toți parametrii obligatorii DEBUG: ParameterBinding Information: : BIND NAMED cmd line args [Get-Service] DEBUG: Informații privind legarea parametrilor: : BIND arg [*] la parametru [Nume] DEBUG: ParameterBinding Information: : COERCE arg to [System String[]] DEBUG: Informații privind legarea parametrilor: : Se încearcă conversia valoarea argumentului de la System String la System String[] DEBUG: ParameterBinding Informații: : ENCODING arg into Colectie DEBUG: Informații privind legarea parametrilor: : colecția de legare Nume parametru: tip argument [String], tip parametru [System String[]], tip colecție Array, tip element [System String], coerceElementType DEBUG: ParameterBinding Information: : Se creează matrice cu tip de element [System String] și elemente DEBUG: ParameterBinding Information: : Tip argument String nu este IList, tratând acest lucru ca pe un scalar DEBUG: ParameterBinding Information: : COERCE arg to [System String] DEBUG: ParameterBinding Informații: : Parametru și arg tipează la fel, nu este nevoie de constrângere DEBUG: ParameterBinding Information: : Adăugarea unui element scalar de tip String la poziția matricei DEBUG: ParameterBinding Informații: : BIND arg [System String[]] la param [Nume] SUCCES DEBUG: ParameterBinding Information: : BIND POSITIONAL cmd line args [Get-Service] DEBUG: Informații privind legarea parametrilor: : VERIFICAREA PARAMETRILOR OBLIGATORII pe cmdlet [Get-Service] Parametrul -Name al Get-Service are, de asemenea, nevoie de o matrice, astfel încât să putem vedea PowerShell creând o matrice cu un singur articol din valoarea noastră de * Rețineți că, până în acest moment, cmdleturile nu s-au executat de fapt; aceasta este doar configurarea PowerShell nu poate face legarea parametrilor conductei până când nu vede ceea ce scoate prima comandă DEBUG: Informații ParameterBinding: : CALLING BeginProcessing DEBUG: Informații ParameterBinding: : CALLING BeginProcessing DEBUG: ParameterBinding Information: : BIND PIPELINE obiect la parametri: [Get-Service] DEBUG: ParameterBinding Information: : PIPELINE obiect TYPE = [System Management Automation PSCustomObj ect] DEBUG: ParameterBinding Information: : RESTAURARE conductă valorile originale ale parametrului Acum executăm comenzi, iar PowerShell știe că trebuie să lege obiectele noastre CSV la ceva din Get-Service DEBUG: ParameterBinding Information: : Parametru [ComputerName] PIPELINE INPUT ValueFromPipelineByPropertyName NO COERTION DEBUG: Informații privind legarea parametrilor: : BIND arg [SERVER-R ] la parametru [ComputerName] PowerShell a ales parametrul -ComputerName și vede că nu este necesară nicio constrângere a datelor Deci prima noastră valoare, SERVER-R , este atașată parametrului -ComputerName DEBUG: Informații privind legarea parametrilor: : colecția de legare parametru ComputerName: tip argument [String], tip parametru [System String[]], tip colecție Array, tip element [System String], fără coerceElementType DEBUG: ParameterBinding Information: : Se creează matrice cu tip de element [System String] și elemente DEBUG: ParameterBinding Information: : Tipul de argument String este nu IList, tratând acest lucru ca pe un scalar DEBUG: ParameterBinding Information: : Adăugarea elementului scalar al tastați String în poziția matricei DEBUG: Informații privind legarea parametrilor: : Se execută VALIDAREA metadate: [System Management Automation ValidateNotNullOrEmptyAttribute] DEBUG: ParameterBinding Information: : BIND arg [System String[]] la parametrul [ComputerName] SUCCES DEBUG: Informații privind legarea parametrilor: : VERIFICAREA PARAMETRILOR OBLIGATORII pe cmdlet [Get-Service] Încă o dată, este așteptată o matrice, astfel încât shell-ul creează o matrice cu un singur articol din valoarea noastră SERVER-R , verifică regulile de validare ale parametrului și se asigură că am furnizat toți parametrii obligatorii pentru comandă: DEBUG: ParameterBinding Information: : BIND PIPELINE obiect la parametri: [Out-Default] DEBUG: ParameterBinding Information: : PIPELINE obiect TYPE = [System Management Automation ErrorRecord] DEBUG: ParameterBinding Information: : RESTAURARE conductă valorile originale ale parametrului DEBUG: Informații privind legarea parametrilor: : Parametrul [InputObject] PIPELINE INPUT ValueFromPipeline FĂRĂ COERȚIE DEBUG: Informații privind legarea parametrilor: : BIND arg [Serviciul nu poate fi deschis Control Manager pe computer „SERVER-R ” Această operație poate necesita alte privilegii ] la parametrul [InputObject] DEBUG: Informații privind legarea parametrilor: : BIND arg [Nu se poate deschide Service Control Manager pe computerul „SERVER-R ” Această operație poate necesita alte privilegii ] pentru a parametriza [InputObject] SUCCESSFUL DEBUG: Informații privind legarea parametrilor: : VERIFICAREA PARAMETRILOR OBLIGATORII pe cmdlet [Out-Default] Ceea ce vedeți aici este o înregistrare de eroare trimisă la Out-Default, deoarece comanda Get-Service nu a putut contacta Managerul de control al serviciului de pe SERVER-R Este în regulă; comanda funcționează, dar este posibil ca computerul să nu fie online sau să fie în spatele unui firewall Ieșirea de urmărire rămasă este mai mult sau mai puțin o repetare a valorii anterioare ale morții, cu valorile rămase din fișierul nostru CSV La final, vedem eroarea comenzii cu privire la SERVER-R : Get-Service : Nu se poate deschide Service Control Manager pe computer „SERVER-R ” Această operațiune poate necesita alte privilegii La linia:l char: + omputers csv | Get-Service -Nume * } + + Categorynfo : NotSpecified: (:) [Get-Service], InvalidOpe rationException + FullyQualifiedErrorld: System InvalidOperationException,Microsoft PowerShell Commands GetServiceCommand PS C:\> Și acum știți cum să depanați legarea parametrilor conductei: folosind Trace-Command, puteți vedea ce date merg la care parametri, ajutându-vă să vă validați așteptările Dar dacă nu ai avut așteptări, nu poți rezolva probleme Este încă important (după cum am explicat în capitolul despre depanare) să înțelegeți ce ar trebui să se întâmple, astfel încât să puteți identifica problema atunci când lucrurile nu se întâmplă așa Creați un fișier text numit C:\Computers csv În el, plasați următorul conținut: Numele calculatorului GAZDĂ LOCALĂ NU ESTE ONLINE Asigurați-vă că nu există linii goale suplimentare la sfârșitul fișierului Apoi, luați în considerare următoarea comandă: Import-CSV C:\Computers txt | Invoke-Command -Script { Get-Service } Fișierul de ajutor pentru Invoke-Command indică faptul că parametrul său -ComputerName acceptă intrarea canalului ByValue Prin urmare, așteptările noastre sunt ca numele computerelor din fișierul CSV să fie transmise la parametrul -ComputerName Dar dacă rulați comanda, nu se întâmplă asta Depanați comanda țiii folosind tehnicile descrise în capitolul țiii și determinați unde sunt legate numele computerelor din fișierul CSV În capitolul , v-am arătat cum să creați obiecte personalizate pe care să le utilizați ca rezultat al funcțiilor dumneavoastră Până la urmă, obiectele pe care le-ați creat au fost în esență plate, ceea ce înseamnă că ar putea fi ușor reprezentate într-un fișier de date plat structura sucii ca fișier CSV sau într-o foaie de calcul Excel sau într-un tabel simplu Asta pentru că obiectele tale, până la urmă, au reprezentat doar o singură entitate, ca un sistem informatic În acest capitol, vă vom arăta cum să lucrați cu obiecte mai complexe care includ mai multe entități într-un singur obiect ierarhic De obicei, un singur obiect ar trebui să reprezinte un singur fel de moarte Acesta ar putea fi un sistem de computer, o unitate de disc, un utilizator sau un fișier Proprietățile acestor obiecte ar trebui să se reia direct la entitatea pe care o reprezintă obiectul De exemplu, dacă creați un obiect care să reprezinte un sistem informatic, atunci acesta ar putea avea proprietăți precum: Numele calculatorului Versiunea sistemului de operare Număr de serie BIOS Numele fabricantului Un obiect computer precum tiiat nu ar conține de obicei multe informații despre unitățile de disc ale computerului Asta pentru că unitățile de disc sunt propria entitate Ele sunt de obicei detașabile din sistemul informatic, iar proprietățile unei unități de disc au puține lucruri de făcut cu sistemul informatic în sine O unitate de disc are o dimensiune, care nu se schimbă atunci când este mutat într-un alt sistem informatic sau când este eliminat cu totul de pe orice computer Dar există, evident, o relație între computere și unități de disc, nu? Un sistem informatic conține de obicei unități de disc Windows Explorer arată această relație într-o vedere arborescentă, așa cum se arată în figura Windows Explorer uses a tree view to illustrate the relationship between a computer and its disk drives Windows Explorer uses a tree view to illustrate the relationship between a computer and its disk drives În PowerShell, puteți reprezenta o relație folosind o ierarhie de obiecte O astfel de ierarhie ar putea fi necesară oricând doriți să combinați informații despre multe entități distincte, dar legate într-un singur obiect de ieșire Înainte de a vă arăta cum să creați și să manipulați aceste ierarhii de obiecte, vrem să vă avertizăm împotriva trimiterii lui într-un fișier CSV De exemplu, încercați să rulați comanda tiiis în PowerShell: Get-Service | Export-CSV Services csv Du-te înainte și alergă tiiis pentru tine; ieșirea merită privită și este puțin mai mult pe care putem să o împărtășim complet în paginile cărții Deschiderea fișierului Services csv în Notepad arată ceva ca în figura Ceea ce vedeți este ceea ce se întâmplă atunci când PowerShell trebuie să convertească o ierarhie de obiecte într-un format de fișier plat, cum ar fi CSV De exemplu, veți vedea că a doua coloană a fișierului CSV tiiis este RequiredServices, care listează serviciile de care depinde fiecare serviciu Dar rândurile de date pentru coloana tiiat arată System ServiceProcess ServiceController [], care este modul Power-Shell de a spune: „Ceea ce ar trebui să meargă aici este un bunii de obiecte ServiceController, dar acest format de fișier nu mă lasă să arăt obiecte copil ” Formatul CliXML folosit de Export-CliXML și Import-CliXML este mult mai bun la reprezentarea ierarhiilor de obiecte Încercați să exportați o listă de servicii în CliXML și să vedeți rezultatul în Windows Notepad De fiecare dată când vedeți un nume de tip de obiect urmat de [], cum ar fi ServiceController [], PowerShell vă anunță: „Aș dori să afișez mai multe subobiecte aici, dar nu pot ” Să trecem printr-un exemplu complet Vom crea o funcție numită Get-DetailedSystemlnfo Dorim ca obiectul principal, de nivel superior, să conțină numele computerului și numerele de versiune ale dispozitivului atât pentru sistemul de operare, cât și pentru pachetul de servicii Fiecare obiect va conține, de asemenea, o proprietate Disks, care va lista informații suplimentare pentru fiecare disc local, fix, instalat în computer Următoarea listă arată fișierul script finalizat, care include o linie la capătul matriței pentru a rula funcția de matriță funcția Get-DetailedSystemlnfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True)][șir[]]ȘcomputerName ) Get OS info Get OS infoPROCES { foreach ($computer in $computerName) { Șparams = ®{computerName=$computer; class='Win OperatingSystem'} $os = Get-WmiObject ®params Șparams = @{computerName=$computer; class='Win LogicalDisk'; filter='drivetype= '} $disks = Get-WmiObject ®params Șparams = @{computerName=$computer; class='Win LogicalDisk'; filter='drivetype= '} $disks = Get-WmiObject ®params Get disk info Get disk info $diskobjs = ®() $diskobjs = ®() Empty array for disks Empty array for disks foreach ($disk in $disks) { $diskprops = ®{Drive=$disk DeviceID; foreach ($disk in $disks) { $diskprops = ®{Drive=$disk DeviceID; Size=$disk size; Size=$disk size; Free=$disk freespace} Free=$disk freespace} Create disk object Create disk object $diskobj = new-object -Type PSObject -Property $diskprops $diskobj = new-object -Type PSObject -Property $diskprops $diskobjs += $diskobj } $diskobjs += $diskobj } $mainprops $mainprops = @{ComputerName=$computer; Disks=$diskobj s; OSVersion=$os version; = @{ComputerName=$computer; Disks=$diskobj s; OSVersion=$os version; Add disk to array Add disk to array Create top- level object Create top- level object SPVersion=$os servicepackmaj orversion} SPVersion=$os servicepackmaj orversion} $mainobject = New-Object -Type PSObject -Property $mainprops $mainobject = New-Object -Type PSObject -Property $mainprops Scrie-Ieșire $mainobject Get-DetailedSystemlnfo -computerName localhost, DONJONES D În cadrul blocului PROCESS al funcției tiiis, începem prin a crea un hashtable care să conțină parametrii pentru primul nostru Get-WmiObject caii și apoi executăm diat caii Această tehnică se numește splatting și poate facilita vizual adăugarea mai multor parametri la o singură comandă În continuare, murim la fel cu Get-WmiObject caii diat ne regăsește informațiile de pe disc Ne facem timp pentru a crea o matrice goală, numită $diskobjs Vom folosi tiiis mai târziu Deoarece fiecare computer pe care îl interogăm ar putea avea mai multe discuri instalate, folosim o buclă ForEach pentru a le parcurge fiecare Pentru fiecare, asamblam un hashtable cu proprietățile pe care vrem să le salvăm pentru fiecare dintre acele discuri Apoi creăm un nou obiect cu acele proprietăți și adăugăm acel obiect la matricea noastră $diskobj Odată ce toate obiectele disc au fost create și salvate în matricea $diskobjs, creăm obiectul de ieșire de nivel superior Îi definim proprietățile, dintre care una este Disks, căreia îi atribuim matricea noastră $diskobjs Vom scoate obiectul principal Ieșirea scriptului, rulată pe două computere, arată ca tiiis: ComputerName SPVersion Discuri OSVersion localhost { Get-service | selectați -ExpandProperty ServicesDependedOn Status Status Running Running Running Stopped Running Running Stopped Running Running Running Running Running Running Running Running Running Running Stopped Running Running Stopped Running Running Running Running Running Running Running Name RPCSS RpcSs CryptSvc AppID RpcSs ProfSvc MMCSS RpcSs AudioEndpointBu rpcss RpcSs WfpLwfs RpcSs EventSystem Name RPCSS RpcSs CryptSvc AppID RpcSs ProfSvc MMCSS RpcSs AudioEndpointBu rpcss RpcSs WfpLwfs RpcSs EventSystem DisplayName DisplayName Remote Procedure Caii (RPC) Remote Procedure Caii (RPC) Cryptographic Services AppID Driver Remote Procedure Caii (RPC) User Profile Service Multimedia Class Scheduler Remote Procedure Caii (RPC) Windows Audio Endpoint Builder Remote Procedure Caii (RPC) Remote Procedure Caii (RPC) WFP LightWeight Filters Remote Procedure Caii (RPC) COM+ Event System Remote Procedure Caii (RPC) Remote Procedure Caii (RPC) Cryptographic Services AppID Driver Remote Procedure Caii (RPC) User Profile Service Multimedia Class Scheduler Remote Procedure Caii (RPC) Windows Audio Endpoint Builder Remote Procedure Caii (RPC) Remote Procedure Caii (RPC) WFP LightWeight Filters Remote Procedure Caii (RPC) COM+ Event System Am trunchiat această ieșire, dar vă arată fiecare „serviciu de care depindea” pentru fiecare serviciu din sistem Veți observa unele repeții, cum ar fi serviciul Remote Procedure Gali, deoarece serviciul respectiv depinde de mai multe alte Servicii Această tehnică este adesea cea mai utilă atunci când lucrați doar cu un singur obiect de nivel superior: PS C:\> Get-service -Name BITS | selectați -ExpandProperty ServicesDependedOn Status Status Running Running Running Running Name RpcSs EventSystem Name RpcSs EventSystem DisplayName DisplayName Remote Procedure Caii (RPC) COM+ Event System Remote Procedure Caii (RPC) COM+ Event System Aici, am preluat doar un singur serviciu, BITS, astfel încât să putem vedea mai clar serviciile de care depinde: RpcSs și EventSystem Comanda Format-Custom, care atunci când este utilizată cu un obiect pentru care nu există nicio vizualizare predefinită, va extinde întreaga ierarhie a obiectului: PS C:\> get-service | format-personalizat -Proprietate * clasa ServiceController { Nume = AllUserlnstallAgent RequiredServices = [ clasa ServiceController { Stare = Running Nume = RPCSS DisplayName = Remote Procedure Caii (RPC) } ] CanPauseAndContinue = Fals CanShutdown = Fals CanStop = Fals DisplayName = Agent de instalare Windows All-User DependentServices = [ ] MachineName = ServiceName = AllUserlnstallAgent ServicesDependedOn = [ clasa ServiceController { Stare = Running Nume = RPCSS DisplayName = Remote Procedure Caii (RPC) } ] ServiceHandle = clasa SafeServiceHandle { Islnvalid = Fals IsClosed = Fals } Stare = oprit ServiceType = Win ShareProcess Site = Container = } clasa ServiceController { Nume = AppIDSvc RequiredServices = clasa ServiceController { Stare = Running Nume = RpcsSs DisplayName = Remote Procedure Caii (RPC) } clasă ServiceController { Stare = Running Nume = CryptSvc DisplayName = Servicii criptografice } clasa ServiceController { Stare = oprit Nume = AppID DisplayName = Driver AppID } ] CanPauseAndContinue = Fals CanShutdown = Fals CanStop = Fals DisplayName = Identitatea aplicației DependentServices = [ ] MachineName = ServiceName = AppIDSvc ServicesDependedOn = [ clasa ServiceController { Stare = Running Nume = RpcsSs DisplayName = Remote Procedure Caii (RPC) } clasă ServiceController { Stare = Running Nume = CryptSvc DisplayName = Servicii criptografice } clasa ServiceController { Stare = oprit Nume = AppID DisplayName = Driver AppID } ] ServiceHandle = clasa SafeServiceHandle { Islnvalid = Fals IsClosed = Fals } Stare = oprit ServiceType = Win ShareProcess Site = Container = } În această listă, puteți vedea că fiecare serviciu a fost extins și ambele proprietăți ServicesDependedOn (afișate și ca RequiredServices) și DependentServices au fost extinse pentru a afișa subobiectele De asemenea, puteți vedea că proprietatea ServiceHandle conține subobiecte de tipul SafeServiceHandle și că acele subobiecte au fiecare două proprietăți Am arătat doar două Servicii aici pentru a economisi spațiu, dar este o ilustrare bună a modului în care poate fi folosit Format-Custom Buclele ForEach sunt o modalitate perfectă de a enumera obiecte, iar buclele ForEach imbricate vă permit să lucrați recursiv cu subobiecte, de exemplu: Șservices = Get-Service foreach ($main service în $services) { Scrieți „ $($main service name) depinde de:” foreach ($sub service în $main service requiredservices) { Scrieți „nu $($sub service name)” } } Iată o parte din rezultatul acelui script scurt: AeLookupSvc depinde de: ALG depinde de: AllUserlnstallAgent depinde de: RPCSS AppIDSvc depinde de: CryptSvc AppID RpcSs Appinfo depinde de: RpcSs ProfSvc AppMgmt depinde de: AudioEndpointBuilder depinde de: Audiosrv depinde de: AudioEndpointBuilder MMCSS RpcSs AxInstSV depinde de: rpcss BDESVC depinde de: BFE depinde de: RpcSs WfpLwfs BITS depinde de: RpcSs EventSystem Infrastructura brokerului depinde de: DcomLaunch RpcEptMapper RpcSs Browserul depinde de: LanmanW orkstation LanmanS e rve r Modul în care vă structurați buclele va depinde de modul în care intenționați să utilizați informațiile, dar, după cum puteți vedea, aveți un control foarte mare asupra modului în care enumerați ierarhia obiectelor În cele din urmă, puteți accesa subobiecte individuale și proprietățile lor utilizând sintaxa de notație matrice a PowerShell: PS C:\> Șservices = get-service PS C:\> $services[ ] requiredservices[ ] nume RpcSs PS C:\> Aici, am tras o listă cu toate serviciile în $services Am accesat al cincilea serviciu (numărul de index ), proprietatea Requiredservices, primul serviciu necesar (numărul de index ) și proprietatea Nume a serviciului, care s-a dovedit a fi RpcSS Creați o nouă funcție în modulul dvs PSHTools existent Nume noua funcție Get-ComputerVolumelnfo Ieșirea acestei funcții va include unele informații pe care le produc deja celelalte funcții, dar această funcție particulară le va combina pe toate într-un singur obiect ierarhic Această funcție ar trebui să accepte unul sau mai multe nume de computer pe un parametru -ComputerName Nu vă faceți griji cu privire la gestionarea erorilor la momentul respectiv Ieșirea acestei funcții ar trebui să fie un obiect personalizat cu următoarele proprietăți: Numele calculatorului OSVersion (versiunea de la Win OperatingSystem) SPVersion (ServicePackMaj sauVersion from Win OperatingSystem) LocalDisks (toate instanțele Win LogicalDisk având un DriveType de ) Servicii (toate instanțe Win Service) Procese (toate instanțele Win ProcessS) Funcția va face cel puțin patru interogări WMI către fiecare computer specificat PowerShell v a introdus un element de limbaj de date pentru shell, conceput pentru a ajuta la separarea textului de codul funcțional al unui script sau al unei comenzi Prin separarea textului, puteți face mai ușor să schimbați versiunile alternative ale textului Separarea textului este denumită globalizare, un proces de pregătire a scriptului pentru localizare Localizatwn vă permite să schimbați șirurile de text în limba originală cu o limbă alternativă sau mai multe limbi Vom recunoaște de la început că tiiis este o caracteristică destul de specializată și că puțini administratori o vor folosi de obicei O includem pentru a ne asigura că cartea tiiat tiiis este cât mai completă posibil, dar o vom păstra pe scurt Puteți găsi ajutor suplimentar în două dintre fișierele de ajutor PowerShell: about script internationalization și despre secțiunile de date Globalizarea (sau integrarea, un termen pe care unii îl preferă) este implementată prin mai multe caracteristici specifice în PowerShell: O secțiune de date, despre care vom discuta în continuare, care conține toate șirurile de text destinate afișării sau ieșirii Două variabile încorporate, $PSCulture și $PSUICulture, care stochează numele limbii interfeței utilizator utilizate de sistemul curent Acest lucru vă permite să detectați limba pe care utilizatorul curent o folosește în Windows $PSCulture conține limba folosită pentru setările regionale, ca date, oră și formate de monedă, în timp ce $PSUICulture conține limba pentru elementele de interfață cu utilizatorul, precum meniuri și șiruri de text ConvertFrom-StringData, un cmdlet tiiat convertește șirurile de text într-un tabel hash, ceea ce face mai ușor să importați un lot de șiruri într-o anumită limbă și apoi să le utilizați din scriptul dumneavoastră Variind formatul lotului pe care îl importați, puteți varia în mod dinamic ceea ce iese scriptul dvs Tipul de fișier psdl, care, pe lângă faptul că este utilizat pentru manifestul modulului, poate fi folosit și pentru a stoca șiruri specifice limbii Furnizați un singur fișier psdl pentru fiecare limbă pe care doriți să o acceptați Import-LocalizedData, un cmdlet diat importă șiruri de text traduse pentru o limbă specifică într-un script Credem că cel mai bun mod de a vă arăta toate acestea este să vă scufundați într-un proiect exemplu și să explicați pe măsură ce mergem, așa că asta este ceea ce vom face Vom începe cu un script simplu din punct de vedere funcțional Afișat în lista , include mai multe instrucțiuni Write-Verbose care scot șiruri de text Ne vom concentra pe acestea pentru eforturile noastre de internaționalizare Pentru exemplele noastre, folosim Google Translate pentru a produce șiruri de text non-engleze; sperăm că toți vorbitorii nativi ai limbilor alese de noi vor ierta orice greșeală de traducere! funcția Get-OSInfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [șir [] ] ȘcomputerName ) ÎNCEPE { Scrieți-verbose „Pornirea Get-OSInfo” } PROCES { Pentru fiecare ($computer în $computername) { încercați { $conectat = $True Scriere-verboză „Încercare $computer” $os = Get-WmiObject -ComputerName $computer -clasa Win OperatingSystem -EA Stop } captură { $conectat = $false Scriere-verboză „Conexiunea la $computer a eșuat” } dacă ($conectat) { Scrieți-verbose „Conexiunea la $computer a reușit” $cs = Get-WmiObject -ComputerName $computer -class Win ComputerSystem $props = @{ComputerName=$computer; OSVersion=$os version; Producător=$cs manufacturer; Model=$cs model} $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } SFÂRŞIT { Scrieți-verbose „Încheierea Get-OSInfo” } } Am folosit caracterul backtick (') în această listă de cod, astfel încât liniile mai lungi să poată fi împărțite în mai multe linii fizice Dacă tastați diis, asigurați-vă că includeți caracterul de backtick și asigurați-vă că este ultimul diing de pe linia matriței - nu poate fi urmat de spații sau file Nu credem că este cel mai frumos mod de a introduce codul, dar îl face mai ușor să-l potriviți în constrângerile paginii tipărite Am salvat acest script ca XDocuments\WindowsPowerShelIXModules\GlobalXGlobal psml Acest lucru ne-a permis să-l încărcăm în consola rulând Import-Module global și să-l testăm rulând Get-OSInfo -computername localhost Dacă aveți de gând să urmați, asigurați-vă că puteți finaliza cu succes acești pași înainte de a continua În prezent, scriptul nostru are șiruri de caractere hardcoded - în primul rând instrucțiunile Write-Verbose, pe care le vom aborda, dar și numele proprietăților obiectelor de ieșire De asemenea, am putea localiza numele proprietăților, dar nu o vom face În general, nici măcar Microsoft nu traduce die, deoarece alte bucăți de cod ar putea avea o dependență de numele proprietăților, iar traducerea diem ar sparge dependența Dacă dorim ca numele de proprietate să afișeze nume de coloane traduse, am putea folosi o vizualizare personalizată pentru a face diat Aruncă o privire la lista următoare, unde am adăugat o secțiune de date pentru a conține șirurile noastre implicite Data section Data section$msgTable = Date { # culture="en-US" ConvertFrom-StringData ®' attempting = Se încearcă connectionTo = Conexiune la eșuată = eșuată succeeded = reușit starting = Începând Get-OSInfo ending = Încheind Get-OSInfo } funcția Get-OSInfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [șir[]]$computerName Using a string Using a stringÎNCEPE { Write-Verbose $msgTable starting } PROCES { Pentru fiecare ($computer în $computername) { încercați { $conectat = $True Scrie-verbose „$($msgTable attempting) $computer” $os = Get-WmiObject -ComputerName $computer -class Win OperatingSystem -EA Stop } prinde { $conectat = $false Scrie-verboză „$($msgTable connectionTo) $computer $($msgTable failed)" } dacă ($conectat) { Scrieți-verbose „$($msgTable connectionTo) pe $computer $($msgTable succeeded)” $cs = Get-WmiObject -ComputerName $computer -class Win ComputerSystem $props = @{ComputerName=$computer; OSVersion=$os version; Producător=$cs manufacturer; Model=$cs model} $obj = New-Object -TypeName PSObject -Proprietate $props Scrie-Ieșire $obj } } } SFÂRŞIT { Scriere-Verbose $msgTable ending } Export- ModuleMember Export- ModuleMember} Export-ModuleMember -funcția „Get-OSInfo” Am adăugat o secțiune de date la Aceasta utilizează cmdlet-ul ConvertFrom-StringData pentru a converti un șir aici într-un tabel hash Rezultatul este un obiect $msgTable, cu proprietăți numite connectionTo, starting, ending și așa mai departe Proprietățile vor conține valorile în limba engleză afișate în script Putem apoi folosi acele proprietăți la , ori de câte ori dorim să afișăm textul asociat Deoarece tiiis este un modul de script, ar face, de obicei, variabila $msgTable accesibilă shell-ului global, odată ce modulul este importat Nu vrem asta; am fi considerat ca $msgTable să rămână folosit intern numai în modulul țiiis Așa că am adăugat și un Export-ModuleMember caii la Prin exportarea funcției noastre Get-OSInfo, orice altceva, adică tot ceea ce nu exportăm în mod explicit, rămâne privat pentru modul și accesibil numai pentru alte legături din fișierul script Vom testa tiiis eliminând modulul, reimportându-l și apoi rulându-l Ne vom asigura că folosim comutatorul -Verbose, astfel încât să putem testa ieșirea noastră localizată Iată cum ar trebui să arate: PS C:\> remove-module global PS C:\> import-modul global PS C:\> Get-OSInfo -computerName gazdă locală Producător OSVersion ComputerName Model VMware, Inc localhost VMware Virtua PS C:\> Get-OSInfo -computerName localhost -verbose VERBOSE: Pornește Get-OSInfo VERBOSE: Încercarea localhost VERBOSE: Conexiunea la localhost a reușit Producător OSVersion СотриterName Model VMware, Inc gazdă locală VMware Virtua VERBOZ: Sfârşit Obțineți-OSInfo După cum puteți vedea, modificările noastre par să aibă succes Rezultatele noastre detaliate sunt afișate cu șiruri corecte în limba engleză Acum putem trece la pasul următor: crearea de versiuni traduse ale șirurilor de caractere Trebuie să setăm câteva fișiere text noi și o structura de director pentru a stoca șirurile traduse Fiecare fișier text va conține o parte din secțiunea noastră de date Vom începe prin a crea următoarele directoare și fișiere noi: \Documents\WindowsPowerShell\Modules\Tools\de-DE\Tools psd \Documents\WmdowsPowerSlielI\Modules\Tools\es\Tools psdl Acest lucru creează două limbi localizate, germană și spaniolă Es și de -DE, precum și tiie en-US utilizate în secțiunea noastră de date, sunt coduri de limbă definite de Microsoft Trebuie să utilizați codurile corecte, așa că asigurați-vă că consultați lista la adresa Cu fișierele create, vom crea comanda noastră ConvertFrom-StringData din scriptul original și în cele două noi fișiere psdl Vom traduce șirurile Următoarele două listări arată rezultatul nostru final După cum am spus mai devreme, aici doar folosim Google Translate; suntem siguri că rezultatele vor fi amuzante pentru oricine știe ce înseamnă acestea de fapt! ConvertFrom-StringData ®' attempting = Versuch connectionTo = Der anschluss an failed = gescheitert succeeded = gelungen starting = Ab Get-OSInfo ending = Ende Get-OSInfo ConvertFrom-StringData @' attempting = Intentar connectionTo = Conexion a failed = fracasado succeeded = exito starting = De la Get-OSInfo ending = Final Get-OSInfo Modul în care tastați șirurile aici este specific Închiderea „ @ nu poate fi indentată; trebuie introdus în primele două caractere ale unui rând, totul de la sine Citiți despre aici șirurile din PowerShell pentru mai multe informații despre acestea Nu suntem pregătiți să ne testăm din nou scriptul; trebuie să-l modificăm pentru a încărca datele translate d Acest lucru se face cu cmdletul Import-LocalizedData și una dintre cele două variabile încorporate pe care le-am menționat mai devreme va juca un rol Cmdletul folosește automat conținutul $PSUICulture pentru a afla ce fișier psdl să importe Asta înseamnă că acest lucru poate fi dificil de testat pe o instalare Windows într-o singură limbă! Am folosit contactele noastre internaționale MVP, care dețin versiuni localizate de Windows, pentru a ne ajuta să testăm acest lucru Următoarea listă arată modificările aduse Global psml pe care le-am făcut $msgTable = Date { # culture="en-US" ConvertFrom-StringData @' attempting = Se încearcă connectionTo = Conexiune la eșuat = eșuat Importing the current language Importing the current languagesucceeded = reușit starting = Începând Get-OSInfo ending = Încheind Get-OSInfo } Import-LocalizedData -BindingVariable $msgTable function Get-OSInfo { [CmdletBinding()] param( [Parametru(Obligatoriu=$True, ValueFromPipeline=$True)] [șir[]]$computerName ) ÎNCEPE { Write-Verbose $msgTable starting } PROCES { Pentru fiecare ($computer în $computername) { încercați { Șconectat = $True Scrie-verbose „$($msgTable attempting) $computer” $os = Get-WmiObject -ComputerName $computer -clasa Win OperatingSystem -EA Stop } captură { $conectat = $false Scrie-verboză „$($msgTable connectionTo) $computer M $($msgTable failed)" } dacă ($conectat) { Scrieți-verbose „$($msgTable connectionTo) pe $computer M $($msgTable succeeded) " $cs = Get-WmiObject -ComputerName $computer -clasa Win ComputerSystem $props = @{ComputerName=$computer; OSVersion=$os version; Producător=$cs manufacturer; Model=$cs model} $obj = New-Object -TypeName PSObject -Property $props Scriere-Ieșire $obj } } } SFÂRŞIT { Scriere-Verbose $msgTable ending } } Export-ModuleMember -funcția „Get-OSInfo” Puteți vedea unde am adăugat comanda Import-LocalizedData la Deoarece tiiis nu este conținut într-o funcție, este executat atunci când modulul nostru este încărcat Lucrul frumos despre comanda tiiis este că citește automat $PSUICulture, pe care l-am menționat, și caută fișierul psdl în subfolderul corespunzător Dacă nu fmd fișierul corect, atunci nu face nimic Asta lasă $msgTable populat cu șirurile noastre originale în limba engleză, devenind astfel valorile noastre implicite Secțiunea de date din scriptul nostru are o sintaxă strictă În general, poate conține doar cmdlet-uri acceptate, cum ar fi ConvertFrom-StringData De asemenea, poate accepta operatorii PowerShell (cu excepția -match), astfel încât să puteți lua decizii logice folosind If Elseif Else construct; nu sunt permise alte constructe de limbaj de scripting Puteți accesa variabilele încorporate $PSCulture, $PSUICulture, $True, $False și $Null , dar nu altele Puteți adăuga și comentarii Mai sunt ceva la ei, dar aceasta este prezentarea generală a ceea ce este permis Nu ești menit să pui mult cod acolo; secțiunile de date sunt destinate să separe datele șirurilor de codul dvs , nu să conțină mai mult cod Nu vedem multe cazuri în care administratorii trebuie să scrie Scripturi localizate, dar cu siguranță le putem imagina Organizațiile internaționale mai mari ar putea dori să depună eforturi pentru a localiza Scripturi, mai ales atunci când rezultatul va fi afișat utilizatorilor finali, radier dian odier administratori Suportul încorporat de la PowerShell pentru gestionarea scripturilor în mai multe limbi este destul de simplu de utilizat și, după cum ați văzut aici, nu este nici măcar dificil să convertiți un script într-o singură limbă în acest format multilingv După cum am menționat în acest capitol, nu vedem multe cazuri în care administratorii trebuie să folosească globalizarea Din acest motiv, nu vă oferim un laborator pentru acest capitol Dar vă încurajăm să urmați exemplul din acest capitol, astfel încât să știți cum funcționează globalizarea în cazul în care o aveți vreodată de folos Până acum, ne-am concentrat să vă menținem în întregime în PowerShell Tot ceea ce v-am arătat până acum a folosit comenzi, tehnici și capabilități native PowerShell Singura excepție a fost scurta noastră scufundare în bazele de date, care ne-a impus să utilizăm NET Framework-ul de bază În acest caz, am încercat în continuare să ascundem un pic Framework-ul, oferindu-vă funcții în stil PowerShell pe care să le utilizați pentru accesul la baza de date Am adoptat această abordare pentru că credem cu adevărat că PowerShell este cel mai ușor și mai consistent atunci când îl utilizați în modul în care am făcut-o În acest capitol, vom trece linia și vom folosi die Framework mai direct Aceasta nu este o abordare pe care o susținem atunci când vă puteți îndeplini sarcina folosind capabilitățile native PowerShell, dar recunoaștem că uneori nu vă puteți baza doar pe ceea ce este încorporat în și pentru PowerShell Totuși, Tiiere este un preț de plătit pentru utilizarea Framework-ului: ieșim din lumea oarecum ordonată a PowerShell Nu va exista ajutor încorporat, iar documentația online pe care ne vom baza este scrisă pentru programatori profesioniști, nu pentru administratori sau scriptori Scripturile noastre PowerShell vor începe neapărat să semene mai mult cu aplicațiile C# și va trebui să ne bazăm mai mult pe tehnicile de programare pentru abordările din linia de comandă NET Framework este organizat într-un set masiv de clase O clasă este practic o bucată de cod care se ocupă de un set specific de sarcini conexe De exemplu, Framework-ul include o clasă numită System Math, care oferă capabilități pentru efectuarea de calcule aritmetice Majoritatea claselor Framework au un nume în mai multe părți așa, indicând faptul că clasa Math face parte din spațiul de nume System În cea mai mare parte, un spațiu de nume este un element organizațional, mucii ca un director de sistem de fișiere Primiți o instanță când încărcați o clasă în memorie, oferindu-i adesea parametri pentru a o dezactiva la un anumit element sau comportament De exemplu, când rulați diis $var = 'Bună ziua!' creați o nouă instanță de sistem String și stocați-l în variabila $var Această instanță a sistemului String este unic și este independent de orice alte instanțe pe care le-ați creat Clasele definesc un număr de proprietăți, proceduri și evenimente pentru ele însele, care sunt denumite în mod colectiv membrii săi Ați lucrat deja intens cu proprietățile și metodele din PowerShell, deoarece obiectele generate de majoritatea comenzilor PowerShell sunt doar instanțe ale unei clase Framework De exemplu, Get-Process produce instanțe ale sistemului Diagnosticare Clasa de proces și acele instanțe au toate proprietățile și metodele cu care sunteți obișnuiți să lucrați Multe clase – System Math fiind un exemplu – au metode statice Un metiiod static este accesibil unui tiiat ca parte a clasei în sine, fără a crea de fapt o instanță a clasei Metodele statice îndeplinesc adesea sarcini generice, care pot fi completate în întregime prin argumentele transmise la metiiod De exemplu, metoda Abs () a clasei Math returnează valoarea absolută a unui număr dat: PS C:\> [System Math] ::Abs(- ) Aceasta arată, de asemenea, sintaxa pentru accesarea unui metiiod static: Includeți numele complet al clasei între paranteze drepte Urmați paranteza de închidere cu două două puncte și specificați numele metiodului Metodele sunt întotdeauna urmate de parendiezi, care conțin o listă separată prin virgulă a argumentelor lui metiiod Nu ar trebui să existe spații oriunde în această sintaxă; totul trebuie să meargă împreună, așa cum am arătat De obicei, puteți scurta numele clasei: PS C:\> [matematică] ::abs(- ) Acest lucru este de obicei permis atunci când lucrați cu o clasă care are un nume unic, neambiguu, ceea ce înseamnă că Framework poate înțelege ce cereți fără să vă întrebați: „Vrei să spui System Math sau SomethingElse Math?” Framework-ul este enorm și nu este încărcat fizic în PowerShell în mod implicit Pe disc, codul tiie Framework este împărțit într-o varietate de ansambluri, care sunt de obicei fișiere DLL Am găsit că majoritatea claselor din spațiul de nume System de nivel superior sunt disponibile în mod implicit, dar pentru alte spații de nume poate fi necesar să încărcați explicit ansamblul necesar pentru a începe să utilizați clasele De exemplu, Microsoft Clasa VisualBasic VBMath nu este încărcată implicit, așa cum puteți vedea din mesajul de eroare atunci când încercăm să folosim metiiodul Rnd () al acesteia: PS C:\> [microsoft visualbasic vbmath]::rnd() Nu se poate găsi tipul [microsoft visualbasic vbmath]: asigurați-vă că ansamblul care conține acest tip este încărcat La linia:l char:l + [microsoft visualbasic vbmath]::rnd() + + Categorynfo : InvalidOperation: (microsoft visualbasic vb math:TypeName) [], RuntimeException + FullyQualifiedErrorld: TypeNotFound În aceste cazuri, puteți încărca manual ansamblul necesar: PS C:\> [system reflection assembly]::loadwithpartialname('Microsoft Visual Basic') | Out-Null Nu, am transmis ieșirea la Out-Null pentru a suprima ieșirea De obicei facem asta atunci când încărcăm ansambluri într-un script, așa că ieșirea lui LoadWithPartialName () nu încurcă rezultatul dorit al scriptului nostru Ar trebui să remarcăm că folosirea LoadWithPartialName () este ușoară, dar este considerată o practică proastă Documentația NET Framework listează metiiodul ca fiind depreciat, ceea ce înseamnă că poate fi eliminat din versiunile viitoare ale tiie Framework Există o postare grozavă pe blog a unuia dintre dezvoltatorii PowerShell, Lee Holmes, care explică detaliile și oferă alternative (și un script de ajutor) la Admitem că vom continua să folosim LoadWithPartialName () pentru că este mult mai simplu și pentru că suntem dispuși să facem orice depanare necesară în rarele ocazii când nu funcționează așa cum avem nevoie cmdletul PowerShell New-Object creează o nouă instanță a unei clase Face acest lucru apelând constructorul unei clase, care vă poate cere să furnizați unul sau mai multe argumente pentru a crea instanța De exemplu, singurul constructor pentru System Drivelnf o class necesită să furnizați un nume de unitate: PS C:\> $drive = New-Object -TypeName System Drivelnfo -Argument 'C:' Când sunt necesare mai multe argumente, furnizați-le parametrului -ArgumentList ca o listă separată prin virgulă Unele clase au mai mulți constructori; New-Object îl va alege pe cel corect pe baza argumentului pe care îl furnizați De exemplu, Sistemul Clasa String oferă o varietate de constructori Nu sunt câteva: String(Char) String(Char []) Șir (Char, Int ) String(Char[], Int , Int ) Fiecare dintre acestea construiește un nou sistem Șir bazat pe o intrare ușor diferită Ultimul, de exemplu, acceptă o matrice de caractere și apoi construiește un șir începând cu caracterul desemnat și incluzând numărul specificat de caractere Acest lucru poate deveni destul de complex, dar ideea este că tipul de date pe care le furnizați în argumentele dvs și ordinea în care enumerați aceste argumente trebuie să se alinieze la unul dintre constructorii furnizați Nu ai putut construi un sistem nou Șir folosind o listă de argumente precum , , deoarece niciunul dintre constructorii clasei nu așteaptă trei numere întregi la rând cmdlet-ul Get-Member de la PowerShell folosește o caracteristică NET Framework numită Reflection În esență, Reflection vă permite să vedeți membrii unui obiect - proprietățile, metodele și evenimentele acestuia - pur și simplu privindu-l Orice instanță NET Framework poate fi transmisă către Get-Member, iar cmdletul vă va arăta cu ce aveți de-a face Acest lucru se aplică numai instanțelor, nu claselor statice; rulează [System Math] | Get-Member nu va produce rezultate utile De exemplu, vom crea o instanță de sistem Clasa IG Drivelnfo, arătând-o către unitatea noastră C: și cereți-i pe Get-Member să ne arate membrii instanței: PS C:\> $drive = New-Object -TypeName System IO Drivelnfo -ArgumentList 'C:' PS C:\> $drive I Obțineți-membru TypeName: System IO Drivelnfo Nume Definiție MemberType Este egal cu GetHashCode GetObj ectData GetType ToString Metoda bool Equals(System Object obj) Metoda int GetHashCode() Metoda System Void GetObjectData(System Runtime metodă GetType() metodă ToString() Proprietate AvailableFreeSpace long AvailableFreeSpace {get;} DriveFormat DriveType Este gata Nume RootDirectory TotalFreeSpace TotalSize VolumeLabel Șir de proprietate DriveFormat {get;} Proprietate System IO DriveType DriveType {get;} Proprietatea bool IsReady {get;} Șir de proprietate Nume {get;} Proprietate System IO Directorylnfo RootDirectory {get;} Proprietate lung TotalFreeSpace {get;} Proprietate lung TotalSize {get;} Șir de proprietate VolumeLabel {get;set;} Aceleași informații sunt disponibile pe pagina de documentație a clasei die la , dar posibilitatea de a le accesa din interiorul shell-ului este convenabilă Google, Bing sau un alt motor de căutare este cel mai bun pariu pentru a găsi documentația de lucru NET Frame De asemenea, puteți începe de la , care este pagina de nivel superior (la momentul scrierii lui) pentru întreaga bibliotecă de documentație a Framework-ului Figura prezintă o parte din pagina de documentație a unei clase După cum puteți vedea, partea de sus a paginii listează numele clasei (Math, parte a spațiului de nume System) și am evidențiat un membru static al clasei Pictograma mare de lângă numele metiiod spune msdn NET Framework din au apreciat acest lucru util - Furnizează metode constante și statice Гог funcții trigonometrice, logaritmice și alte funcții matematice comune Sistem Matematică Namespacei The System,Math,Log() method see- , Visual Ce Exprees not have The System,Math,Log() method see- , Visual Ce Exprees not have Assemblvi mscorllb (în mscorlib dll) Matematică Tipul Math expune următorii membri Nume Descriere Returnează valoarea absolută a unui număr '* Returnează supapa absolută a unui număr în virgulă mobilă dublu-precllon Returnează supapa absolută a unui număr întreg slgned de blt Găsirea numelui ansamblului unei clase și a metodelor sale statice ne spune că aceasta este o metodă statică; am putea face clic pe numele mediod pentru a afla mai multe despre cum să-l folosim În figura , am trecut la die Spațiul de nume System Diagnostice și clasa Process conținea dierein Am evidențiat atât o proprietate de instanță Învechit Obține si« din memoria virtuală a procesului ud Obține cantitatea de memorie virtuală alocată procesului asociat ud Învechit Obține utilizarea memoriei fizice a procesului asociat Ud- Obține cantitatea de memorie fizică alocată procesului asociat Nume Descriere Începe operațiunile de citire asincrone pe fluxul redirecționat al aplicatlon^ Începe operațiunile de citire asincrone pe fluxul redirecționat al aplicatlon Anulează operația de citire asincronă pe fluxul redirecționat al unui aplicatlon Anulează operația de citire asincronă pe fluxul redirecționat al unui aplicatlon Eliberează toate resursele care sunt asociate Proprietăți și metode ale instanțelor char [] chars = { w, 'o', V char [] chars = { w, 'o', V sxrinj : iccoparaoit, ICloneable, IConvertlble, ICoeparable , lEntxreablet IEnu*erable, IEquatable Tipul String txp-osește următorii membri, Nume Descriere * Inițializează o nouă instanță a clasei String la valoarea Indicată de un punct specificat într-o matrice de caractere Unicode ■ У гм Inițializează o nouă Instanță a clasei String la valoarea Indlcated de o matrice de caractere Unicode, ** Inițializează o nouă Instanță a clasei String la valoarea indicată de un pointer la o matrice de numere întregi S-biți Inițializează o nouă Instanță a clasei String la valoarea Indlcated de un caracter Unicode specificat, repetat de un anumit număr de ori '* Inițializează o nouă instanță a clasei String la valoarea Indicată de un pointer specificat la o matrice de caractere Unicode, o poziție de caracter de pornire în cadrul acelei matrice și o lungime * Inițializează o nouă instanță a clasei String la valoarea Indicată de o matrice de caractere Unicode, o poziție de început a caracterului în cadrul acelei matrice și o lungime Inițializează o nouă instanță a clasei String la valoarea indicată de un pointer specificat la o matrice de -blt semnate Constructorii sistemului Clasa de șiruri (WorkingSet) și o metodă de instanță (BeginOutputReadLine ()) Amintiți-vă că ambele sunt accesibile numai dintr-o instanță activă a clasei die, mai mult decât ca membri statici În cele din urmă, în figura arătăm sistemul Clasa String și evidențierea unora dintre constructorii săi Acești constructori oferă diferite moduri de a crea o nouă instanță a clasei tiie Dacă documentația arată un mic programator, ei bine, ar trebui să fie Amintiți -vă, am părăsit confoanele confortabile ale PowerShell și ne-am aventurat în lumea programatorilor Folosim chestii, așa că trebuie să citim că face Rețineți că sunt mai mult decât câteva versiuni ale NET Framework out tiiere; PowerShell v folosește Framework v , așa că deseori veți dori să vă uitați în mod special la documentația pentru versiunea Cu cât utilizați mai mult NET Framework, PowerShell devine mai puțin eficient în a vă ajuta să faceți acest lucru Asta pentru că PowerShell nu a fost conceput ca un mediu de dezvoltare NET; Microsoft oferă Visual Studio pentru tiiat Dacă descoperiți că trebuie să împrumutați un pic de cadru într-un script PowerShell, probabil că sunteți bine; dacă vă uitați la un script PowerShell care a crescut la sute de linii și constă în principal din chestii Framework, probabil v-ar fi mai ușor să treceți la Visual Studio și să îmbrățișați C# sau un alt limbaj NET (cum ar fi Visual Basic) Am văzut administratorii lansând sute de linii din ceea ce este în esență cod simplificat C# (sintaxa lui PowerShell este, până la urmă, bazată parțial pe sintaxa C#), oferind o scuză: „Nu am timp să învăț C#” Economiile de timp pe care Visual Studio le-ar fi oferit ar fi compensat mai mult curba de învățare Visual Studio oferă un mediu de dezvoltare, instrumente, experiență de depanare și așa mai departe, acestea sunt special concepute pentru a lucra cu NET Acesta este ceva de care vrem să țineți cont Dacă lucrul cu NET în PowerShell pare puțin dificil uneori, asta se datorează faptului că PowerShell nu a fost niciodată proiectat pentru a face din asta o experiență super lină Capacitatea de a accesa Framework-ul din PowerShell este ceva pe care ar trebui să îl considerați ca funcționalitate bonus, nu misiunea principală a PowerShell NET Framework conține o clasă numită Dns, care locuiește în spațiul de nume System Net Citiți documentația acesteia la Acordați o atenție deosebită procedurii statice GetHostEntry () Utilizați metoda tiiis pentru a returna adresa IP a În această ultimă parte a cărții, vom analiza fabricarea de instrumente din unul dintre cele mai comune cazuri de utilizare: administrarea delegată Vă vom arăta cum să construiți instrumente care sunt destinate utilizatorilor mai puțin tehnici sau mai puțin privilegiați Cu cât implementați un instrument bazat pe GUI pentru utilizatorii finali sau configurați administrarea delegată pentru biroul de asistență al organizației dvs , aceste tehnici sunt cele pe care le veți folosi din nou și din nou Aceste tehnici devin mai complexe decât ceea ce am acoperit până acum și se bazează pe o gamă largă de tehnologii, care sunt din punct de vedere tehnic în afara PowerShell în sine Vom rămâne cu misiunea noastră de a nu încerca să fim cuprinzătoare, ci mai mult de a ne concentra pe elementele de bază și de a vă ajuta să înțelegeți lucrurile în mod mai precis Aceste capitole vor lăsa mult loc pentru o explorare independentă ulterioară, dar ne vom asigura că știți suficient pentru a fi eficient la tiiat În acest capitol și în cele două de după acesta, vă vom arăta cum să utilizați PowerShell pentru a construi o aplicație de interfață grafică cu utilizatorul (GUI), potrivită pentru distribuție către utilizatorii finali Rețineți că nicio modalitate de a compila diis într-un diat executabil nu are nevoie de PowerShell pentru a rula, dar vom putea face diis să semene mult cu o aplicație Windows reală Înainte de a scrie acest capitol, ne-am gândit îndelung ce direcții să luăm, pentru că atunci când vine vorba de construirea unei GUI avem mai multe Am decis să folosim Windows Forms (WinForms), unul dintre cele două sisteme GUI NET Framework De asemenea, am decis, în cea mai mare parte, să ne bazăm pe un instrument comercial numit PowerShell Studio ( ) pentru a construi o aplicație GUI Nu vom munci de fapt fiii din spatele acestor decizii aici; am fi mai ales cu sarcina pe care o avem la îndemână Dar ar trebui să înțelegeți raționamentul nostru și alte opțiuni, așa că am scris o scurtă anexă la această carte, pe care o veți găsi online la Acolo vă explicăm diferitele alegeri cu care ne-am confruntat și de ce am procedat așa cum am procedat Ne dăm seama că aceasta este o investiție financiară cu PowerShell Studio, dar presupunem că majoritatea cititorilor noștri sunt profesioniști IT care lucrează într-un mediu corporativ, unde se presupune că există un buget pentru instrumente pentru a vă face treaba WinForms este cel mai vechi dintre cele două sisteme GUI ale Microsoft din NET Framework Acesta a fost alăturat în NET v de Windows Presentation Foundation (WPF), care este un sistem independent WPF nu înlocuiește WinForms, dar oferă capabilități ceva mai moderne Am crezut că WinForms este mai simplu de lucrat, așa că acesta este ceea ce am decis să folosim Aplicațiile WinForms se bazează pe ideea a formular sau fereastră Fiecare fereastră din aplicația dvs - o casetă de dialog, un ecran de ieșire sau orice altceva - este un formular Fiecare element dintr-un formular este denumit control și poate include elemente precum butoane, etichete, casete de text, butoane radio, casete de validare și toate elementele GUI Windows cunoscute Fiecare formă și control are o varietate de proprietăți care controlează aspectul și, în anumite privințe, comportamentul lor Controalele sunt doar un fel de obiect, mucii ca obiectele produse de comenzile PowerShell La fel ca obiectele, diey au proprietăți Au, de asemenea , evenimente, care reprezintă tiiings care se pot întâmpla cu controlul De exemplu, făcând clic pe un buton declanșează un anumit eveniment pentru controlul tiiat Putem atașa comenzile PowerShell ca handlere evmt, iar WinForms va executa anumite comenzi ca răspuns la eveniment Așa vom face formularul nostru interactiv Formele și controalele sunt create prin instanțierea unei instanțe a clasei respective Odată ce aveți o instanță a unui control, puteți să setați proprietățile acestuia și să atașați handlere de evenimente Controalele au nume, care vă permit să vă referiți la tiiem mai ușor În PowerShell, vom stoca controalele într-o variabilă, astfel încât să faceți referire la ele este încă mai ușoară Controalele dintr-un formular includ proprietățile WinForms unde să poziționeze controlul pe formular Prin manipularea acestor proprietăți, puteți crea aspectul exact de care aveți nevoie Ar trebui să subliniem că nu vom încerca să vă facem un expert în WinForms în această serie de capitole - am avea nevoie de o carte întreagă pentru a face acest lucru Scopul nostru este să vă introducem în tehnologie și tehnicile acesteia printr-un exemplu simplu, ca o modalitate de a începe Din tiiere, poți continua să înveți și să explorezi pe cont propriu Vă sugerăm propria bibliotecă MSDN a Microsoft ca o referință excelentă la WinForms; vizitați portalul WinForms Este complet posibil să creați o interfață grafică folosind nimic mai mult decât editorul ISE nativ PowerShell, dar este o durere uriașă în gât Vă vom arăta cum să faceți asta oricum, dar vom începe cu un instrument care elimină cea mai mare parte a durerii din proces Acest instrument, PowerShell Studio, este un instrument comercial, ceea ce înseamnă că trebuie să plătiți pentru el Are o probă gratuită de de zile, așa că sperăm că va fi suficient pentru a vă ajuta să treceți prin această carte Producătorul său, SAPIEN Technologies, oferă, de asemenea, o ediție comunitară gratuită a predecesorului instrumentului, PrimalForms Această versiune este puțin funcțională, dar dacă ești îngrijorat doar de crearea de Scripturi simple care utilizează o singură formă (fereastră), probabil că va face o treabă grozavă pentru tine În această serie de capitole, ne vom baza pe Power Shell Studio ; dacă utilizați o versiune diferită, vă așteptați ca capturile de ecran să fie cel puțin oarecum diferite După cum se arată în figura , vom începe prin a crea un nou proiect de formulare Acest lucru ne oferă un formular de bază, gol, pentru a începe widi Vă încurajăm cu tărie să urmați această demonstrație pas cu pas Procedând astfel, vă veți simți mai bine setul de instrumente și vă va ajuta să lucrați mult mai rapid la propriile proiecte Vom personaliza un pic formularul Nu îl vom redimensiona chiar acum - vom aștepta până când vom avea unele comenzi pentru a face asta - dar vom configura unele dintre aparițiile și comportamentele sale mai ciudate Folosind lista de proprietăți din partea dreaptă a aplicației, vom seta următoarele: FormBorderStyle la FixedDialog—Acest lucru face un formular neredimensionabil, deși vom putea în continuare să ajustam dimensiunea pe care o dorim în timp ce o proiectăm MinimizeBox și MaximizeBox to False—Aceste elimină butoanele de minimizare și maximizare din bara de titlu a ferestrei, dar lasă butonul de închidere StartPosition to CenterScreen—Acest lucru controlează unde apare formularul când se deschide pentru prima dată Text la „Demo de creare de instrumente”—Acest lucru personalizează textul din bara de tiie a ferestrei Este adesea mai ușor dacă modificați lista de proprietăți pentru a enumera proprietățile în ordine alfabetică, făcând clic pe butonul AZ chiar deasupra listei Acum trebuie să ajustam proprietățile acestor controale Primul Labei: Setați Text la „Introduceți numele computerului:” Casetă de text: Setați numele la „ComputerName” Al doilea Labei: Setați Textul la „Selectați jurnalul evenimentelor:” Setați Vizibil la Fals ComboBox: Setați numele la „EventLogName” Setați DropDownStyle la „DropDownList” Setați Vizibil la Fals Dar ton: Setați numele la „Butonul OK” Setați Textul la „OK” Figura prezintă aspectul revizuit al formularului Asta e practic tot ce trebuie să facem! Ne vom asigura că salvăm proiectul în acest moment, așa că nu pierdem nimic dacă ceva nu merge bine, dar designul general al formei este finalizat Rețineți că a trebuit să ne gândim la ce ar face diis și nu v-am împărtășit procesul de proiectare, deoarece acum ne concentrăm pe mecanica matriței de a finaliza i Start Page j X al -> [ И =: |:j Options Context Î? И и J Peneis ’ Help Edit Windows Help i Start Page j X al -> [ И =: |:j Options Context Î? И и J Peneis ’ Help Edit Windows Help Debug Debug ” Ptojert’ File’ Debug Debug Debug ” Ptojert’ File’ Debug Lucrul frumos despre PowerShell Studio este că poate crea scriptul PowerShell necesar pentru a implementa interfața grafică pe care am proiectat-o Am folosit opțiunea Export to Clipboard File pentru a crea scriptul prezentat în figura Acest script este masiv: sunt necesare aproape de linii doar pentru a crea interfața grafică simplă pe care am proiectat-o Nu vom enumera totul aici, dar vrem să vă atragem atenția asupra câteva fragmente Mai întâi este secțiunea care încarcă piesele NET Framework necesare pentru a crea interfața grafică: [gol] [reflecție asamblare] Încărcare ("System, Version= , Cuiture=neutrai, PublicKeyToken=b a c e ") [void] [reflection assembly]::Load("System Windows Forms, Version= , Cuiture=neutrai, PublicKeyToken=b a c e ") [void] [reflection assembly]::Load("System Drawing, Version= , Cultură=neutru, PublicKeyToken=b f f flld a a") [void] [reflection assembly]::Load("mscorlib, Version= , Cuiture=neutrai, PublicKeyToken=b a c e ") [void] [reflection assembly]::Load("System Data, Version= , Cuiture=neutrai, PublicKeyToken=b a c e ") [void] [reflection assembly]::Load("System Xml, Version= , Cuiture=neutrai, PublicKeyToken=b a c e ") [gol] [reflecție asamblare] Load ( "System DirectoryServices , Versiunea= , Cuiture=neutral, PublicKeyToken=b f f flld a a") л • ' = | | Fișier Edi Vie* T« $ Debug Add-с*»! Hei? țj “ □ у ț* ij» ■ î В И Q Г ; | Unlnedl nsr X □ ]::LOld( LoidC : LO&d( ] : :Load( Lo&dC LoaoC S ' ■ ■ :Enib eVisuelStylesO ІЛ СЫ I % Iată cum este creată GUI-ul în cod, mai degrabă decât într-un instrument de proiectare GUI Urmează codul pentru a crea diferitele elemente GUI pe care le-am proiectat Observați că numele variabilelor reflectă proprietatea Name pe care am atribuit-o în PowerShell Studio Butonul nostru, de exemplu, este reprezentat de $OKButton și caseta noastră de text de $ Сотри terName Elementele pentru care nu le-am atribuit un nume specific au primit nume generice, cum ar fi $LabelSelectEventLog [System Windows Forms Application]::EnableVisualStyles() $MainForm = Obiect nou „System Windows Forms Form” $OKButton = Obiect nou 'System Windows Forms Button' $labelSelectEventLog = Obiect nou 'System Windows Forms Labei' $EventLogName = Obiect nou 'System Windows Forms ComboBox' $ComputerName = Nou- Obiect „System Windows Forms TextBox” $labelEnterComputerName = Obiect nou „System Windows Forms Labei” $InitialFormWindowState = Obiect nou „System Windows Forms FormWindowState” În cele din urmă, există mai multe secțiuni care atribuie valorile inițiale ale proprietăților noastre Неге, de exemplu, sunt proprietățile pentru formularul principal și pentru butonul nostru: # MainForm # $MainForm Controls Add($OKButton) $MainForm Controls Add($labelSelectEventLog) $MainForm Controls Add($EventLogName) $MainForm Controls Add($ComputerName) $MainForm Controls Add($labelEnterComputerName) $MainForm ClientSize = ' , ' $MainForm FormBorderStyle = 'FixedDialog' $MainForm MaximizeBox = $False $MainForm MinimizeBox = $False $MainForm Name = "MainForm" $MainForm StartPosition = 'CenterScreen' $MainForm Text = „Demonstrație de creare de instrumente” $MainForm add Load($OnLoadFormEvent) # butonul OK # $ KButton Location = ' , ' $ KButton Name = „Buton OK” $OKButton Size = ' , ' $OKButton Tablndex = $OKButton Text = „OK” $OKButton UseVisualStyleBackColor = $True Exact așa ar arăta codarea manuală a acestei GUI După cum puteți vedea, este destul de extins Există, de asemenea, o mulțime de încercări și erori implicate, în special în ceea ce privește proprietățile de locație și dimensiune ale comenzilor Pentru a fi sincer, am mai făcut aceste lucruri codificate manual și nu le vom mai face niciodată Prețul pentru PowerShell Studio este mai mult decât corect, având în vedere cât timp am pierdut încercând să codificăm manual aceste lucruri mici în trecut Afișarea GUI este o simplă chestiune de rulare a scriptului Putem face acest lucru chiar în PowerShell Studio, făcând clic pe Run Prqject în fila Home a panglicii sale Sau, pentru că am exportat deja scriptul de die în clipboard și l-am lipit în die PowerShell ISE, l-am putea rula acolo Când facem acest lucru, obținem afișajul matriței prezentat în figura Fiecare zi nu este perfectă După cum puteți vedea, introduceți numele computerului: labei este puțin tăiat Acest lucru a fost vizibil în PowerShell Studio mai devreme și am refuzat să-l reparăm Putem merge mai departe și face asta acum, în timp ce facem orice alte modificări vizuale care sunt necesare Eticheta noastră Select Event Log, de exemplu, era puțin scurtă, așa că partea de jos a g era tăiată Acest lucru este, de asemenea, ușor de remediat, ajustând tiie labei înapoi în PowerShell Studio După ce am făcut toate ajustările noastre vizuale, suntem gata cu formularul și suntem gata să trecem la cod Vom continua să construim pe acest exemplu de GUI în următoarele două capitole, așa că vă încurajăm să vă asigurați că urmați În tiiis lab veți începe un proiect cu care veți lucra în următoarele câteva capitole, așa că veți dori să vă asigurați că aveți o soluție funcțională înainte de a continua Dezvoltarea unui script PowerShell grafic este întotdeauna mai ușoară dacă aveți un script de linie de comandă funcțional Am făcut deja acea parte pentru tine în lista următoare Funcția Get-ServiceData { [cmdletbinding()] Param( [parametru(Posiție= , Obligatoriu=$True,HelpMessage="Introduceți un nume de computer")] [ValidateNotNullorEmpty()] [șir]$Computername, [Parametru(Poziție=l)] [ValidateSet("Running","Oprit","Toate","%")] [șir]$Filter="Toate" ) Încerca { Scrieți-verbose „Obținerea serviciilor $filter de la $numecomputer” dacă ($Filter -eq „Toate”) { $filter='%' Scriere-Verbose „Utilizarea filtrului WMI: starea ca „$Filter”” } $services=Get-WmiObject -Class Win Service -ComputerName $Computername -filtru „State Like „$Filter”” #scrie rezultatele selectate în conductă $servicii | Selectați Nume, Nume afișat, Stat, Mod Start, Nume Start } Captură { Avertisment de scriere „Eșuat la obținerea serviciilor de la $Computername $ Exception Message” } } Funcția #end Puteți fie să reintroduceți, fie să descărcați scriptul de pe MoreLunches com Funcția ia un nume de computer ca parametru și primește Servicii prin WMI pe baza criteriilor de filtrare furnizate de utilizator Funcția scrie un subset de date pe linia de conductă Din linia de comandă ar putea fi folosit astfel: Get-servicedata $env:computername -filter rulează | Out-GridView Sarcina dvs în acest laborator este să creați o formă grafică folosind PowerShell Studio Ar trebui să ajungeți să aveți ceva asemănător cu forma de matriță prezentată în figura Bifați în mod implicit butonul radio Running Veți găsi mai ușor mai târziu dacă puneți butoanele radio într-un control GroupBox, plus că arată mai cool Scriptul pe care îl creați nu trebuie să facă nimic pentru acest laborator exceptand afisarea diis forma Dispunerea formularului În capitolul anterior, am creat o interfață grafică de utilizator pentru scriptul nostru PowerShell; în acest capitol, vom începe să adăugăm codul necesar pentru a face ca GUI să funcționeze Vom continua să lucrăm în PowerShell Studio Dar tot ceea ce facem va fi mult mai intens de cod, ceea ce înseamnă că ați putea alege să utilizați instrumentul doar pentru a crea GUI, creați și lipiți codul de creare a GUI în PowerShell ISE și, de acolo, puteți lucra în ISE Când am pus PowerShell Studio să creeze un script care implementează GUI, a atribuit controalele noastre GLn variabilelor Aceste variabile au fost denumite pe baza a ceea ce am atribuit proprietății Nume a controalelor noastre, astfel încât caseta de text Computername se află în variabila $ComputerName Pentru controale pe care nu le-am denumit în mod explicit, instrumentul a creat un nume - adesea bazat pe proprietatea Text a controalelor, cum ar fi $LabelEnterComputerName Întotdeauna facem un punct de a numi în mod explicit orice control cu care intenționăm să lucrăm sau cu care utilizatorii interacționează, astfel încât să putem avea un nume de variabilă concis și sensibil Vom folosi acele variabile pentru a adresa și accesa controalele GUI sau obiectele Când sunt urmate de un punct, ne vor lăsa să accesăm proprietăți, cum ar fi $ComputerName Text, care oferă acces la orice a fost introdus în caseta de text Caseta de text este un bun exemplu Nu trebuie să ne îngrijorăm când utilizatorul face ceva cu el; îi vom lăsa să scrie orice vor Când sunt terminați, ei vor face clic pe butonul OK și vom citi conținutul casetei de text - așa este, orice a fost tastat - folosind $ComputerName Text Pot exista momente când vă pasă de interacțiunea utilizatorului cu o casetă de text; ați putea, de exemplu, să doriți să puteți întreprinde anumite acțiuni în timp ce un utilizator tastează Puteți face asta cu siguranță; trebuie doar să faceți dublu clic pe caseta de text a matriței în PowerShell Studio și veți deschide un handler de evenimente gol pentru evenimentul de modificare a casetei de text a matriței, care se declanșează de fiecare dată când se schimbă conținutul casetei de text Fiți atenți cu diat, deoarece dacă din handlerul de evenimente widiin diat modificați conținutul casetei de text die, veți declanșa un eveniment Change anodier, care poate duce la o buclă infinită Dacă doriți ca caseta de text cu numele computerului să fie implicită pentru computerul local, în panoul de script fmd die form Funcția de încărcare și adăugați o linie de cod pentru a actualiza valoarea die Text a controlului dvs , cum ar fi diis: $formMenu Load= { #TODO: Inițializați controalele formularului aici ȘComputername text=$env:computername } Vă sugerăm să folosiți variabila de mediu în loc de localhost, deoarece unele comenzi nu vor recunoaște localhost ca nume de computer Butonul OK este puțin diferit Ne pasă de interacțiunile utilizatorilor cu acel control Îl vom pune să îndeplinească o sarcină dublă, ceea ce înseamnă că îi vom pune pe utilizatori să facă clic pe el o dată pentru a afișa mai târziu caseta noastră cu listă derulantă și din nou pentru a interoga o listă de intrări din jurnalul de evenimente În PowerShell Studio, vom face dublu clic pe butonul pentru a crea și a deschide un handler de evenimente pentru evenimentul Click al butonului die Acest lucru ne duce într-un cod, sau script, vizualizare, unde putem introduce comenzile pe care dorim să le rulăm atunci când se face clic pe butonul die Pentru moment, vom introduce câteva bucăți de cod, așa cum se arată în figura Dar vom popula cea mai mare parte a codului diis în secțiunea următoare când ne vom ocupa de caseta noastră listă Codul nostru de până acum arată ca tiiis: $OKButton Click={ if ($EventLogName Visible) { preluați jurnalul de evenimente } altfel { completați lista de jurnal de evenimente $logs = Get-EventLog -ComputerName $ComputerName Text -Listă } } Ceea ce facem este să verificăm starea casetei noastre drop-down $EventLogName, în special, starea proprietății sale Vizibile Dacă lista derulantă nu este vizibilă (ceea ce nu este pentru a începe cu, pentru că am setat acea proprietate la False când am proiectat GUI-ul în capitolul anterior), vom completa lista derulantă cu evenimentul nume de jurnal с* с* itUOu itUOu Home Export Heip Home Export Heip С Сору С Сору HTML Paste ,, u Cui Clipboatd С Сору С Сору HTML Paste ,, u Cui Clipboatd Bit Bit [ STA Mode Execution Policy Platform [ STA Mode Execution Policy Platform Run Proiect’ Run Proiect’ Run Stop File’ Script Run Run Stop File’ Script Run Debug Debug Project’ F>le’ Debug Debug Debug Project’ F>le’ Debug Edil Edil Navsgatron Navsgatron Nawgation Nawgation l Start Pape HM OpUoni Panels ’ Windows l Start Pape HM OpUoni Panels ’ Windows Fиндол Ехріан Fиндол Ехріан E “Lr Toortaking gGiob^apsi WeriFampff E “Lr Toortaking gGiob^apsi WeriFampff AddRange( ) AddRange( ) Objecl Brows« Objecl Brows« FWfcrm & FWfcrm & Ge-M» Get-AjthenfosaeSpn GetCMolem Gel Command Get Compui ecRwt ore I Get-Cort ert Gel Cartat GetCredertai Ge-M» Get-AjthenfosaeSpn GetCMolem Gel Command Get Compui ecRwt ore I Get-Cort ert Gel Cartat GetCredertai Get-Event Ga-Everilog Get-Event Ga-Everilog Items AddRange( Items AddRange( [Array]) [Array]) ■BeginUpd«tf() ■BeginUpd«tf() Ițeai Add( Ițeai Add( ,EndUpdate() ,EndUpdate() , Ițeai Add( jj" , Ițeai Add( jj" Di splayMenbe- Di splayMenbe- MariFwm pff MariFwm pff i Event* i Event* LoadCcmboSox LoadCcmboSox OKButton Ckfc OKButton Ckfc Ge Function E - i Properties Srrppets ’ a x -l G FowerSbel A D^»sse i Escapes Nes , Fom Rnebcrti JJtes , vjbSabcn VBScript ic Power , ЛМІ РъгкЬх Aovance Background Jco ( Ji Backgnxnd Job v Function E - i Properties Srrppets ’ a x -l G FowerSbel A D^»sse i Escapes Nes , Fom Rnebcrti JJtes , vjbSabcn VBScript ic Power , ЛМІ РъгкЬх Aovance Background Jco ( Ji Backgnxnd Job v L a rsole Debug CArtput - —Q— —I— + u- Auto layout | READ OVR -AP ним UTF L a rsole Debug CArtput - —Q— —I— + u- Auto layout | READ OVR -AP ним UTF Gelter Prepery Get-Job Gelter Prepery Get-Job The OK button’s Click event handler The OK button’s Click event handler După cum puteți vedea, combinăm comenzile PowerShell familiare cu proprietățile matrițelor controalelor noastre GUI Este nevoie de puțin să te obișnuiești, dar cu puțină practică vei ajunge acolo În acest moment, am salvat intrările din jurnalul de evenimente solicitate în variabila $entries și suntem gata să facem ceva cu aceste informații Figura arată gestionarea evenimentelor Click din butonul nostru OK până acum Asigurați-vă că urmați În capitolul următor, vom continua să construim pe asta, așa că nu vrem să vă pierdem! Iată codul complet (l-am trunchiat puțin): $OKButton Click={ if ($EventLogName Visible) { preluați jurnalul de evenimente if ($EventLogName Selectedlndex -gt - ) { $entries = Get-EventLog -Computer $ComputerName Text -Log $EventLogName Selectedltem } } altfel { completați lista de jurnal de evenimente $logs = Get-EventLog -ComputerName $ComputerName Text -Lista | Select-Object-ExpandProperty Log Încărcare-ComboBox -ComboBox $EventLogName -Articole $jurnal $EventLogName Visible = $true $labelSelectEventLog Visible = $true } } Dacă utilizați PowerShell Studio, asigurați-vă că descărcați exemplul de cod pentru această carte din Am inclus completați fișierul de proiect PowerShell Studio pentru proiectul finalizat, astfel încât să îl puteți deschide și să îl rulați singur Exemplul la care am lucrat nu are nevoie de diem, dar vrem să ne asigurăm că vedeți mai multe controale în acțiune pe care probabil le veți folosi Mai întâi sunt butoanele radio Un buton radio este un set de opțiuni care se exclud reciproc Prin tiiat ne referim la tiiat doar un singur buton radio poate fi bifat la un moment dat Controlul are o proprietate Verificată pe care o puteți testa sau seta Valoarea este mai mult $True sau $False Iată un exemplu de formular în figura Vă recomandăm să setați un buton radio implicit pentru formularul dvs Pentru a utiliza, testați fiecare buton radio pentru a vedea dacă este bifat Iată un exemplu de cod care se află în spatele acestui formular: $buttonOK Click={ #TODO: plasați aici un script personalizat dacă ($radiobuttonServices Checked) { $Title="Servicii pentru $(Școmputername Text)" Get-Service -ComputerName ȘComputername Text | Out-GridView -Titlu **• $Titlu } elseif ($radiobuttonProcesses Verificat) { $Title="Procese pentru $($computername Text)" Get-Process -ComputerName $Computername Text | Out-GridView -Titlu b* $Titlu } elseif ($radiobuttonDiskSpace Checked) { $Title="DiskSpace pentru $($computername Text)" Get-WMIObject -Class Win LogicalDisk -Filter ”DriveType= ” - ComputerName $Computername Text | Selectați DeviceID,Size,Frespace,Volume Out-GridView -Title $Title } else { #asta nu ar trebui să se întâmple niciodată Avertisment de scriere „Nu s-a putut determina ce buton radio este bifat” Amintiți-vă că am spus că puteți verifica un singur buton radio la un moment dat? Asta pe formă sau grupare Dacă aveți un set de butoane radio, puteți adăuga un control GroupBox și plasați butoanele radio în el În cadrul grupării matrițelor, puteți avea doar un singur buton radio bifat Figura demonstrează cum ar putea arăta diis Încă trebuie să testați proprietatea Verificată a fiecărui buton radio Un alt control similar este caseta de selectare În timp ce butoanele radio se exclud reciproc, puteți bifa câte casete doriți Și acestea au o proprietate Checked pe care o puteți seta și testa Figura ilustrează cum ar putea arăta o casetă de selectare Ca și butoane radio, puteți testa proprietatea Verificat și puteți răspunde în consecință $buttonOK Click={ #TODO: plasați aici un script personalizat dacă ($checkboxPing Checked) { if (Test-Conexiune -ComputerName ȘComputername Text -Quiet) { $pinged=$true } altfel { Avertisment de scriere „Eșuat la ping $($computername text)” $pinged=$False } } altfel { #nu testa ping, presupunem că putem $pinged=$Adevărat } Dacă ($pinged) { $data=Get-WmiObject -Class Win ComputerSystem -ComputerName $Computername Text } if ($checkboxLogResults Checked) { $export=Calea de alăturare -Calea „$env:userprofile\documents” -ChildPath „$($Computername Text)-CS xml” $date | Export-Clixml -Cale $export Obține-articol $export | vizualizare în afara rețelei } else { $date | vizualizare în afara rețelei } } Pentru formularele complexe, puteți, de asemenea, să plasați casetele de selectare în GroupBox Controls PowerShell Studio oferă, evident, mai multe controale decât putem acoperi aici Puteți face clic dreapta pe un control și puteți obține ajutor pentru acesta Meniul Ajutor are, de asemenea, un link către o serie de mostre, astfel încât să puteți vedea multe dintre aceste controale în acțiune În acest laborator, veți continua de unde ați rămas în capitolul Dacă nu ați terminat, vă rugăm să faceți acest lucru mai întâi sau să descărcați soluția eșantion de pe MoreLunches com Acum trebuie să vă conectați formularul și să puneți câteva acțiuni în spatele controalelor numele computerului local real Nu folosi localhost Căutați funcția de eveniment Încărcare a formularului de matriță Apoi, conectați butonul OK, astfel încât să ruleze funcția Get-ServiceData din laboratorul din capitolul și să transmită rezultatele către conductă Puteți modifica funcția dacă doriți Lizați formularul Controale pentru a transmite parametrii funcției Puteți evita erorile dacă setați comportamentul implicit pentru a căuta Servicii care rulează Vă puteți testa formularul trimițând rezultate către Out-String și apoi Write-Host De exemplu, în formularul dvs puteți ajunge cu o linie ca tiiis: | Out-String | Scrie-gazdă În capitolul următor veți învăța modalități mai bune de a gestiona ieșirea formularelor În cele două capitole anterioare, v-am arătat cum să creați o interfață grafică și să îi adăugați funcții În acest capitol, vom lua această funcționalitate și o vom folosi pentru a crea unele rezultate pentru utilizatorul aplicației Ne vom concentra pe două tehnici: modalitatea ușoară, încorporată de afișare generică a rezultatelor și modul mai greu și mai personalizat de a vă construi propriul formular de ieșire Vom începe prin a folosi cmdlet-ul Out-GridView, care va fi disponibil pe orice computer care are instalat PowerShell ISE Vom face o modificare minoră în gestionarea butonului OK al aplicației noastre; Tiie handler complet este listat aici: $OKButton Click={ if ($EventLogName Visible) { preluați jurnalul de evenimente if ($EventLogName Selectedlndex -gt - ) { $entries = Get-EventLog -Computer $ComputerName Text -Log $EventLogName Selectedltem Șentries | Out-GridView } } altfel { completați lista de jurnal de evenimente $logs = Get-EventLog -ComputerName $ComputerName Text -Lista | Select-Object-ExpandProperty Log Încărcare-ComboBox -ComboBox $EventLogName -Articole $jurnal $EventLogName Visible = $true $labelSelectEventLog Visible = $true } } Am transmis $entries către Out-GridView Am fi putut transfera ieșirea Get-EventLog direct către Out-GridView, dar având intrările de jurnal în variabila $entries ne va fi mai ușor să demonstram următoarea tehnică de ieșire Acum vom rula scriptul nostru pentru prima dată, făcând clic pe Run Project în PowerShell Studio Figura prezintă prima formă care apare Vom introduce „localhost” și facem clic pe OK După cum se arată în figura , ni se oferă o listă derulantă cu toate jurnalele de aplicații disponibile de pe computer Vom selecta Aplicație și vom face clic pe OK a doua oară În cele din urmă, figura arată ce face Out-GridView: ne afișează rezultatul într-o grilă interactivă care poate fi sortată, filtrabilă Credem că aceasta este o modalitate excelentă de a afișa chiar și rezultate complexe utilizatorilor finali, deoarece le permite să continue să lucreze cu date și nu necesită efort din partea noastră! Acum pentru câteva note de depanare: PowerShell Studio poate rula scripturi în unul dintre cele două moduri pe un sistem pe de biți: de biți și de biți Pe computerul nostru cu Windows pe de biți, trebuia să rulăm scriptul în modul pe de biți pentru ca Out-GridView să funcționeze Puteți alege modul diis folosind o listă derulantă din fila Acasă a PowerShell Studio Cmdletul Get-EventLog necesită Serviciul de registru la distanță pe computere la distanță (chiar dacă vă conectați la localhost), care a fost dezactivat pe computerul nostru cu Windows A trebuit să activăm și să începem serviciul die pentru ca cmdletul să funcționeze Când nu am făcut-o, am primit o eroare când am încercat să populam lista derulantă Dacă User Account Control (UAC) este activat, poate fi necesar să rulați Scripturile în modul Elevat Acesta este, de asemenea, ales din lista derulantă din fila Acasă a PowerShell Studio J« > M nwle Help | “* De*: - —u— + ’ Auto Layout | READ OVR CAP HUM UTF- J« > M nwle Help | “* De*: - —u— + ’ Auto Layout | READ OVR CAP HUM UTF- O- ( O- ( Ѵеиліоп YBSciipi lo Power WM! Ѵеиліоп YBSciipi lo Power WM! Secksnxjnd Job ( „’j Зккjnxmd Job v Secksnxjnd Job ( „’j Зккjnxmd Job v The results, shown in Out-GridView The results, shown in Out-GridView Dacă alegeți să nu utilizați Out-GridView sau dacă nu este potrivit pentru nevoile dvs , atunci va trebui să vă „roii propriul” formular de ieșire Pentru a continua exemplul nostru, vom comenta comanda Out-GridView din handlerul de evenimente al butonului OK: $OKButton Click={ if ($EventLogName Visible) { preluați jurnalul de evenimente if ($EventLogName Selectedlndex -gt - ) { $entries = Get-EventLog -Computer $ComputerName Text -Log $EventLogName Selectedltem # $intrari | Out-GridView } } altfel { completați lista de jurnal de evenimente $logs = Get-EventLog -ComputerName $ComputerName Text -Lista | Select-Object-ExpandProperty Log Încărcare-ComboBox -ComboBox $EventLogName -Articole $jurnal $EventLogName Visible = $true $labelSelectEventLog Visible = $true } } Astfel, putem adopta o abordare complet nouă Vom construi un al doilea formular în cadrul proiectului nostru PowerShell Studio Acest formular va fi, de asemenea, o casetă de dialog fixă și va afișa doar numele computerului și numărul de intrări ale jurnalului de evenimente care au fost găsite în jurnalul specificat În figura , veți vedea că am folosit fila Fișier pentru a deschide meniul Nou, selectând Formular nou Open Project Open Project СЮіе Project СЮіе Project Oil-Shrft-O Oil-Shrft-O Ctrt-s Ctrt-s i «l^gTJa'oțl [ îGro-oBox fi HlerpProwdr dScralBr "чде L at A -ebel * |$‘ ь $c ь $c Proprietăți Adăugarea fișierului Formular Rezultate la proiectul nostru de creare de instrumente SAPltN Powerbheir Studio V CnxSetj licrpicft ,Л‘ЗМап Mjrugene CnxSetj licrpicft ,Л‘ЗМап Mjrugene PSOagnostcs PSOagnostcs După cum se arată în figura , vom selecta și opțiunea de a copia fișierul în folderul proiectului În acest fel, toate fișierele matrițe sunt conținute într-un singur folder, ceea ce este mai convenabil Acum, cu siguranță, am fi putut crea o formă de matriță chiar în proiect, pentru început, făcând clic dreapta pe folderul proiectului Toolmaking din PowerShell Studio și selectând Adăugare fișier nou din acesta Dar modul în care am făcut-o este o abordare comună și am vrut să ne asigurăm că știi cum să o faci Scriptul nostru, în cazul în care exportăm întregul proiect într-un fișier script PS , ar consta acum din trei funcții Funcția Main () este cea care pune în funcțiune scriptul și afișează fereastra formularului inițial Aceasta este gestionată de funcția tiie Call-MainForm pf f O a doua funcție, Call-Results pff, implementează acum noul formular Rezultate Deoarece toate aceste funcții trăiesc în script, ele pot „vedea” fiecare otiier, deși nu pot vedea în interiorul fiecărui otiier Formularul nostru Rezultate și toate controalele sale nici măcar nu există până când Call-Results pf f este apelat, așa că acesta va fi primul lucru pe care trebuie să-l facem în gestionarea principală a evenimentelor butonului OK: $OKButton Click={ if ($EventLogName Visible) { # preluați jurnalul de evenimente if ($EventLogName Selectedlndex -gt - ) { $entries = Get-EventLog -Computer $ComputerName Text -Log $EventLogName SelectedItem #$intrari | Out-GridView Call-Results pff } } altfel { # completați lista de jurnal de evenimente $logs = Get-EventLog -ComputerName $ComputerName Text -Lista | Select-Object-ExpandProperty Log Încărcare-ComboBox -ComboBox $EventLogName -Articole $jurnal $EventLogName Visible = $true $labelSelectEventLog Visible = $true } } Făcând asta, arată instantaneu și formularul, care nu arată atât de bine acum, deoarece nu l-am populat Trucul va fi să trecem cumva informațiile noastre în noua funcție, astfel încât formularul Rezultate să poată „vedea” informațiile pe care vrem să le folosească Există o mulțime de moduri în care am putea face asta, dar o vom face prin deschiderea fișierului Globals psl din PowerShell Studio creat automat în proiectul nostru În partea de sus, vom declara o nouă variabilă numită $global events și o vom seta să fie o matrice goală Figura prezintă adaosul Înapoi în gestionarea de evenimente butonul OK, acum vom pune rezultatele Get-EventLog în $global events în loc de $entries Figura prezintă această modificare Deoarece $global events este global, va fi vizibil și în formularul nostru Rezultate Există deja un handler de evenimente în scriptul formularului de rezultate care va rula când formularul este încărcat Figura arată ce i-am adăugat • W- Ы F Сору ■— Сору HTML Bd (Ridicat) ' Й Modul STA Politica de execuție Run Run Stop Proiect' F»le* Script Proiect de depanare' * Fișier de depanare- *■ U • ' Editați Navigator | Pagina de pornire FM Optlons Ц? Pantli ' В Concurs Ajutor Pastă * Ftle E—— Depanați Windows Ajutor sAPltN Powerbhei» stuChO V PrCfKt В •, I 'ooHakog Gbbaie Marfo RmAi Ajutor pentru export □bject Browse* ■» p x - PWfCmr & - ГѴ rvpa "WT» Mjb Ml saev sbp к $й * □bject Browse* ■» p x - PWfCmr & - ГѴ rvpa "WT» Mjb Ml saev sbp к $й * $RichTextBoxResults Text=$date | Out-String Ultima opțiune, deși cea mai complicată din grup, este un control DataGridView Acesta este ca ceea ce obțineți când trimiteți rezultatele către Out-Gridview, cu excepția faptului că tabelul este în formularul dvs Puneți date în control prin proprietatea DataSource, care este o matrice de valori obligatorii Din fericire, PowerShell Studio are o funcție de ajutor numită Load-DataGridView, care facilitează completarea acesteia Iată un fragment de cod despre cum ar putea arăta: ștergeți grila $datagridviewl ClearSelection() #Obțineți date $date=Get-WmiObject Win LogicalDisk -Filter "drivetype= " -ComputerName $Computername Text | Selectați „DeviceID”,@{Name="SizeGB";Expression={"{ :N }" -f ($ Size/ GB)}}, @{Name="FreeGB"/Expression={"{ :N }" -f ($ Freespace/ GB)}}, „NumeVolum” #adăugați datele la control Load-DataGridView -DataGridView $datagridviewl -Articol $date Veți găsi fișiere de proiect demo PowerShell Studio pentru aceste comenzi Vom păstra lucrurile destul de simple pentru acest laborator Folosind proiectul de laborator PowerShell Studio din capitolul , adăugați un control RichTextBox pentru a afișa rezultatele Nu sunt câteva lucruri de reținut: Configurați controlul pentru a utiliza un font cu lățime fixă, cum ar fi Consolas sau Courier New Proprietatea Text trebuie să fie un șir, deci formatați în mod explicit datele ca șiruri de caractere utilizând Out-String Utilizați metoda Clear () a controlului pentru a o reseta sau pentru a șterge orice rezultat existent Dacă trebuie să mutați lucrurile pe formular, este în regulă Puteți descărca un exemplu de soluție de la O funcție proxy acționează ca un wrapper în jurul unei funcții, cmdlet sau comenzi otiier existente În forma sa cea mai simplă, o funcție proxy transmite toate intrările de parametri către comanda wrapped Funcțiile proxy sunt utilizate în mod obișnuit pentru a adăuga parametri, pentru a elimina parametri sau pentru a extinde sau a restricționa comanda subiacentă, devenind un instrument util pentru administrarea delegată De exemplu, ați putea oferi utilizatorilor o funcție proxy care elimină un parametru de comandă la care nu doriți ca utilizatorul să aibă acces Când este încărcată, o funcție proxy ascunde oarecum comanda reală, încapsulată Combinate cu tehnici precum punctul final de telecomandă constrâns (pe care vom trata în capitolul următor), funcțiile proxy pot ascunde complet comanda înfășurată, devenind doar mijloace prin care un utilizator poate îndeplini o anumită sarcină O funcție proxy, pe care unii oameni o numesc o funcție de wrapper, este concepută pentru a sta deasupra unei comenzi existente De exemplu, dacă creați o funcție proxy numită ConvertTo-HTML, aceasta va ascunde cmdlet-ul real ConvertTo-HTML Indiferent de parametrii pe care îi furnizați ca parte a funcției proxy vor deveni singurii disponibili pentru utilizatori, permițându-vă să eliminați funcționalitate, să adăugați funcționalitate și așa mai departe Funcțiile proxy pot fi, de asemenea, folosite pentru a crea comenzi complet noi și, sub capotă, să profite de funcționalitatea unei comenzi existente De exemplu, vă vom arăta cum să creați o comandă Export-HTML care utilizează în mod intern ConvertTo-HTML și Out-File, lăsând totuși accesul independent la botii de cmdlet-uri native Primul pas în crearea unei funcții proxy este crearea șablonului PowerShell face acest lucru pentru tine, așa că este un pas destul de ușor Rezultatul este o funcție care arată și funcționează exact ca cea originală - în esență o parte a acesteia Veți folosi șablonul diis ca punct de plecare pentru redenumirea funcției matriței, adăugarea parametrilor sau eliminarea parametrilor Vom începe cu cmdlet-ul ConvertTo-HTML Scopul nostru este de a crea o funcție proxy numită Export-HTML, care adaugă un parametru -FilePath, astfel încât HTML-ul convertit să poată fi scris direct într-un fișier De asemenea, vom elimina întregul set de parametri diat include parametrul die -Fragment, deoarece nu are sens (cel puțin pentru cazul nostru de utilizare) să scriem un fragment HTML într-un fișier Deoarece nu denumim funcția ConvertTo-HTML, cmdlet-ul original va rămâne accesibil Vom începe prin a rula două comenzi: PS C:\> $metadata = New-Object System Management Automation CommandMetaData (Get-Command ConvertTo-HTML) PS C:\> [System Management Automation ProxyCommand]::Create($metadata) | Fă-ți fișierul NewScript ps! Vă încurajăm cu tărie să urmați și comenzile și editările scripturilor noastre Scriptul produs de PowerShell nu se potrivește perfect în paginile acestei cărți, dar vom limita numărul de modificări pe care le facem acelei formatări pentru a încerca să menținem scriptul cât mai consistent cu ceea ce veți vedea dacă faceți acest lucru tiiis pe cont propriu Rezultă un fișier, NewScript psl, care este afișat în lista următoare Veți observa că acesta este doar un script, nu o funcție reală [CmdletBinding(DefaultParameterSetName='Pagină', HelpUri='http:// go microsoft corn/fwlink/?LinkID= ', RemotingCapability='None')] param( [Parametru(ValueFromPipeline=$true)] [psobj ect] ${InputObj ect}, [Parametru(Poziție= )] [System Object [] ] ${Property}, [Parameter(ParameterSetName='Pagină', Poziție= )] [șir [] ] ${Body}, [Parameter(ParameterSetName='Pagină', Poziție=l)] [șir [] ] ${Head}, [Parameter(ParameterSetName='Pagină', Poziție= )] [ValidateNotNullOrEmpty()] [şir] ${Title}, [ValidateNotNullOrEmpty()] [ValidateSet('Tabel','Lista')] [şir] ${As}, [Parameter(ParameterSetName='Pagina')] [Alias('cu','uri')] [ValidateNotNullOrEmpty()] [System Uri] ${CssUri}, [Parameter(ParameterSetName='Fragment')] [ValidateNotNullOrEmpty()] [intrerupator] ${Fragment}, [ValidateNotNullOrEmpty()] [șir [] ] ${PostContent}, [ValidateNotNullOrEmpty()] [șir [] ] ${PreContent}) ÎNCEPE { încerca { $outBuffer = $null if ($PSBoundParameters TryGetValue('OutBuffer', [ref]$outBuffer)) { $PSBoundParameters['OutBuffer'] = } $wrappedCmd = $ExecutionContext InvokeCommand GetCommand('ConvertTo- Html', [System Management Automation CommandTypes]::Cmdlet) $scriptCmd = {& $wrappedCmd @PSBoundParameters } $steppablePipeline = $scriptCmd GetSteppablePipeline($mylnvocation CommandOrigin) $steppablePipeline Begin($PSCmdlet) } captură { arunca } } proces { încerca { $steppablePipeline Process($ ) } captură { arunca } } Sfârşit { încerca { $steppablePipeline End() } captură { arunca } } Vom include acest lucru într-o funcție numită Export-HTML De asemenea, pentru a face acest lucru un pic mai ușor de încărcat și utilizat, vom salva imediat fișierul ca modul de script Vom salva fișierul ca \Documents\WindowsPowerShell\Modules\Proxies\Proxies psml De asemenea, vom continua și vom redenumi funcția proxy, așa cum se arată în listing , deoarece acest proxy nu mai folosește aceeași sintaxă ca și comanda originală În timp ce suntem atit, vom elimina și linkul către documentația de comandă online a Microsoft Modificările din lista următoare sunt afișate cu caractere aldine funcția Export-HTML { [CmdletBinding(DefaultParameterSetName= Pagina , RemotingCapability= Niciunul )] param( [Parametru(ValueFromPipeline=$true)] [psobj ect] ${InputObj ect}, [Parametru(Poziție= )] [System Object[]] ${Property}, [Parameter(ParameterSetName='Pagină', Poziție= )] [șir [] ] ${Body}, [Parameter(ParameterSetName='Pagină', Poziție=l)] [șir [] ] ${Head}, [Parameter(ParameterSetName='Pagină', Poziție= )] [ValidateNotNullOrEmpty()] [şir] ${Title}, [ValidateNotNullOrEmpty()] [ValidateSet('Tabel','Lista')] [şir] ${As}, [Parameter(ParameterSetName='Pagina')] [Alias('cu','uri')] [ValidateNotNullOrEmpty()] [System Uri] ${CssUri}, [Parameter(ParameterSetName='Fragment')] [ValidateNotNullOrEmpty()] [intrerupator] ${Fragment}, [ValidateNotNullOrEmpty()] [șir [] ] ${PostContent}, [ValidateNotNullOrEmpty()] [șir [] ] ${PreContent}) ÎNCEPE { încerca { $outBuffer = $null if ($PSBoundParameters TryGetValue('OutBuffer', [ref]$outBuffer)) { $PSBoundParameters['OutBuffer'] = } $wrappedCmd = $ExecutionContext InvokeCommand GetCommand('ConvertTo-Html', [System Management Automation CommandTypes]::Cmdlet) $scriptCmd = {& $wrappedCmd @PSBoundParameters } $steppablePipeline = $scriptCmd GetSteppablePipeline($mylnvocation CommandOrigin) $steppablePipeline Begin($PSCmdlet) } captură { arunca } } proces { încerca { $steppablePipeline Process($ ) } captură { arunca } } Sfârşit { încerca { $steppablePipeline End() } captură { arunca } } Vom începe prin a elimina parametrul -Fragment, care este singurul parametru din setul de parametri Fragment Este al treilea până ultimul parametru definit în script chiar acum, după $CssUri și înainte de $ Post Content Următoarea listă arată fișierul Proxies psml modificat, căruia îi lipsește acum un parametru -Fragment funcția Export-HTML { [CmdletBinding(DefaultParameterSetName='Pagină', RemotingCapability='Niciuna')] param( [Parametru(ValueFromPipeline=$true)] [psobj ect] ${InputObj ect}, [Parametru(Poziție= )] [System Obj ect[]] ${Proprietate}, [Parameter(ParameterSetName='Pagină', Poziție= )] [șir [] ] ${Body}, [Parameter(ParameterSetName='Pagină', Poziție=l)] [șir [] ] ${Head}, [Parameter(ParameterSetName='Pagină', Poziție= )] [ValidateNotNullOrEmpty()] [şir] ${Title}, [ValidateNotNullOrEmpty()] [ValidateSet('Tabel','Lista')] [șir] ${As}, [Parameter(ParameterSetName='Pagina')] [Alias('cu','uri')] [ValidateNotNullOrEmpty()] [System Uri] ${CssUri}, [ValidateNotNullOrEmpty() ] [șir [] ] ${PostContent}, [ValidateNotNullOrEmpty() ] [șir [] ] ${PreContent}) începe { încercați { $outBuffer = $null dacă ($PSBoundParameters TryGetValue('OutBuffer', [ref]$outBuffer)) { $PSBoundParameters['OutBuffer'] = } $wrappedCmd = $ExecutionContext InvokeCommand GetCommand('ConvertTo-Html', [System Management Automation CommandTypes]::Cmdlet) $scriptCmd = {& $wrappedCmd @PSBoundParameters } $steppablePipeline = $scriptCmd GetSteppablePipeline($mylnvocation CommandOrigin) $steppablePipeline Begin($PSCmdlet) } captură { arunca } } proces { încerca { $steppablePipeline Process($ ) } captură { arunca } } Sfârşit { încerca { $steppablePipeline End() } captură { arunca } } } În acest moment, putem sări în shell și să încercăm asta: PS C:\> proxy-uri pentru modul de import PS C:\> ajutor export-html NUME ConvertTo-Html SINTAXĂ ConvertTo-Html [[-Property] ] [ [-Head] ] [[-Title] ] [ [-Body] ] [ - InputObj ect ] [-As {Tabel | List}] [-CssUri ] [-PostContent ] [-PreContent ] [ ] ConvertTo-Html [[-Property] ] [-InputObject ] [-As {Tabel | List}] [-Fragment] [-PostContent ] [-PreContent ] [ ] Puteți vedea că conținutul de ajutor afișează în continuare ConvertTo-HTML, iar parametrul die -Fragment este încă afișat Este în regulă; ceea ce este important este că shell-ul a recunoscut comanda noastră Export-HTML Confuzia fișierului de ajutor vine de la aceste două linii de la sfârșitul funcției: Vom elimina acum două rânduri, vom salva din nou scriptul și vom încerca din nou: PS C:\> proxy-uri de eliminare a modulelor; proxy-uri pentru modul de import PS C:\> ajutor export-html NUME Export-HTML SINTAXĂ Export-HTML [[-Property] ] [[-Head] ] [ [-Title] ] [ [-Body] ] [-InputObject ] [-As {Tabel | List}] [-CssUri ] [-PostContent ] [-PreContent ] [ ] Toate, asta e mult mai bine Setul de parametri Fragment a dispărut, iar ajutorul arată corect numele funcției noastre Vom începe prin a declara un parametru -FilePath Vom face acestea la sfârșitul listei de parametri existente, așa că vă vom arăta ultimul parametru original ca referință Rețineți că trebuie să adăugați o virgulă după ultimul parametru original, astfel încât lista de parametri va continua să includă noul nostru parametru De asemenea, trebuia să mutăm închiderea ) din blocul Param: Original -PreContent parameter Original -PreContent parameter New-FilePath parameter New-FilePath parameter[ValidateNotNullOrEmpty()] [șir [] ] ${PreContent}, [Parametru(Obligatoriu=$True)] [ValidateNotNullOrEmpty()] [șir] $FilePath) Am folosit $FilePath mai degrabă decât ${FilePath}; botii au acelasi efect Șablonul produs de PowerShell folosește doar parantezele ca un fel de precauție mai bună-sicuritate-scuze; știm că tiiat $FilePath este un nume de variabilă legal, așa că nu avem nevoie de paranteze Acum trebuie să facem noul nostru parametru să funcționeze Pentru a face tiiat, localizați această secțiune a șablonului: ÎNCEPE { încerca { $outBuffer = $null dacă ($PSBoundParameters TryGetValue('OutBuffer', [ref]$outBuffer)) { $PSBoundParameters['OutBuffer'] = } $wrappedCmd = $ExecutionContext InvokeCommand GetCommand('ConvertTo-Html', [System Management Automation CommandTypes]::Cmdlet) $scriptCmd = {& $wrappedCmd @PSBoundParameters } $steppablePipeline = $scriptCmd GetSteppablePipeline($mylnvocation CommandOrigin) $steppablePipeline Begin($PSCmdlet) } prinde { arunc } } Trebuie doar să modificăm în jurul acestei linii: $scriptCmd = {& $wrappedCmd @PSBoundParameters } Noul cod va arăta astfel: $PSBoundParameters Remove('FilePath') | Out-Null $scriptCmd = {& $wrappedCmd @PSBoundParameters | În afara fișierului $filePath } Acest lucru elimină parametrul nostru -FilePath din colecția de parametri, deoarece ConvertTo-HTML subiacent nu va ști ce să facă cu el Apoi permitem rularea ConvertTo-HTML inițial, dar ieșirea acestuia este transmisă către Out-File și furnizăm fișierului Out-Fi valoarea parametrului nostru $f ilePath Orice alți parametri au fost specificați pentru funcția noastră, toți vor fi în $PSBoundParameters și, deoarece toți sunt validi cu ConvertTo-HTML, îi trecem prin „splatting” themas@PSBoundParameters Următoarea listă arată Proxies psml revizuit funcția Export-HTML { [CmdletBinding(DefaultParameterSetName='Pagină', RemotingCapability='Niciuna')] param( [Parametru(ValueFromPipeline=$true)] [psobj ect] ${InputObj ect}, [Parametru(Poziție= )] [System Object[]] ${Property}, [Parameter(ParameterSetName='Pagină', Poziție= )] [șir [] ] ${Body}, [Parameter(ParameterSetName='Pagină', Poziție=l)] [șir [] ] ${Head}, [Parameter(ParameterSetName='Pagină', Poziție= )] [ValidateNotNullOrEmpty()] [şir] ${Title}, [ValidateNotNullOrEmpty()] [ValidateSet('Tabel','Lista')] [şir] ${As}, [Parameter(ParameterSetName='Pagina')] [Alias(' cu' , 'uri')] [ValidateNotNullOrEmpty()] [System Uri] ${CssUri}, [ValidateNotNullOrEmpty()] [șir [] ] ${PostContent}, [ValidateNotNullOrEmpty()] [șir [] ] ${PreContent}, [Parametru(Obligatoriu=$True)] [ValidateNotNullOrEmpty()] [şir] $FilePath) ÎNCEPE { încerca { $outBuffer = $null if ($PSBoundParameters TryGetValue('OutBuffer', [ref]$outBuffer)) { $PSBoundParameters['OutBuffer'] = } $wrappedCmd = $ExecutionContext InvokeCommand GetCommand('ConvertTo-Html', [System Management Automation CommandTypes]::Cmdlet) $PSBoundParameters Remove('FilePath') | Out-Null $scriptCmd = {& $wrappedCmd @PSBoundParameters | În afara fișierului $filePath } $steppablePipeline = $scriptCmd GetSteppablePipeline($mylnvocation CommandOrigin) $steppablePipeline Begin($PSCmdlet) } captură { arunca } } proces încerca { $steppablePipeline Process($ ) } captură { arunca } } Sfârşit { încerca { $steppablePipeline End() } captură { arunca } } Ca un test rapid, am reimportat modulul nostru și am încercat să exportăm o listă de procese care rulează în HTML Figura prezintă rezultatele În partea de jos a ecranului, puteți vedea comenzile pe care le-am executat, iar Internet Explorer arată fișierul rezultat Л Л lol JK к i = ! ia s | | r ~ > | C:\procs html P- e TABEL HTML >:| BasePriority ExitCode a ieșit ExitTime Handle HandleCount ID MachineName MainWiadowHaodle MainWindot a Э Fals b Fals Fals Fals Fals = Fals Fals V PS C:\> elimina-modul proxy; import- proxy module PS Ci\> get-prooess export-html -FilePath procs rtml * PS CA> T n Testarea comenzii Export-HTML Există câteva reguli cu privire la funcțiile proxy atunci când vine timpul să le încărcați Deoarece exemplul nostru a folosit un nou nume de comandă, Export-HTML, este capabil să coexiste cu comanda originală, ConvertTo-HTML Dar dacă ne-am fi numit funcția ConvertTo-HTML, am fi eliminat efectiv accesul ușor la ConvertTo-HTML original Când două comenzi încărcate au același nume, PowerShell îl primește pe ultima încărcată implicit Pentru a rula originalul, ar fi trebuit să rulăm cumva ca: PS C:\> Get-Process | Microsoft PowerShell Utility\ConvertTo-HTML Specificând numele modulului în care se află comanda originală, îl putem accesa și ocoli o funcție proxy care folosește același nume Desigur, abilitatea de a ocoli funcția proxy ar putea să nu fie ceva ce doriți să permiteți În acest caz, ar trebui să oferiți doar acces la funcția dvs proxy prin Remoting Prin crearea unui punct final de Remoting constrâns (acesta este subiectul capitolului următor), puteți permite ca numai funcția dvs proxy să fie vizibilă pentru utilizatori, interzicând accesul la comanda originală, permițând în același timp funcția proxy să utilizeze funcționalitatea comenzii originale Creați o funcție proxy pentru cmdletul Export-CSV Denumiți funcția proxy Export-TDF Eliminați parametrul -Delimiter și, în schimb, codificați-l pentru a utiliza întotdeauna -Delimiter „'t” (acesta este un backtick, urmat de litera t, între ghilimele duble) Lucrați cu funcția proxy într-un fișier script În partea de jos a fișierului, după închiderea } a funcției, puneți următoarele pentru a testa funcția: Get-Service | Export-TDF c:\services tdf Rulați scriptul pentru a testa funcția și verificați dacă creează un fișier delimitat de tabulatori numit c:\^ervices tdf Capacitatea de a crea puncte finale constrânse a existat încă de la PowerShell v , dar PowerShell v le face mai ușor de creat și le face o modalitate eficientă de a configura capabilități de administrare delegate în mediul dumneavoastră Vă vom ghida prin procesul complet de creare și configurare a acestora și vă vom oferi câteva idei despre cum le puteți utiliza în propria organizație Figura oferă o privire de ansamblu rapidă asupra arhitecturii PowerShell Remoting Utilizați protocolul Web Services for Management (WS-MAN) pentru a comunica între computere (sau chiar între două Servicii de pe același computer) WS-MAN utilizează mai multe HTTP sau HTTPS, HTTP fiind implicit Pe un computer la distanță , un serviciu Windows Remote Management (WinRM) primește traficul WS-MAN de intrare și direcționează traficul către unul sau mai multe puncte finale Când anumite puncte terminale se conectează la PowerShell, o configurație de sesiune determină capacitățile unei anumite conexiuni Configurațiile implicite de sesiune create atunci când activați Remoting (prin rularea Enable-PSRemoting) sunt practic nerestricționate și pot fi utilizate numai de administratori Pentru o privire mai detaliată asupra modului în care funcționează Remoting, vă recomandăm Aflați „Windows PowerShell într-o lună de prânz” De asemenea, puteți consulta ghidul gratuit de Don’s Secrets of PowerShell Remoting , care este disponibil la Pentru acest capitol, vom presupune că computerul la care lucrați are deja activată Remoting (rulați Enable-PSRemoting ca administrator acceptând toate setările implicite și asigurați-vă că comanda este finalizată fără eroare) COMPUTER DE LA DISTANTA = owerShe exe Pcwe r Shell exe Oricare ar fi exe Punct final: PowerShell -brt \ / Punct final: PowerShe -b't \ / Endpo'nt; Ceva în sine Get-PSSessionConfiguration -Name Net* Name PSVersion StartupScript RunAsUser Permission Name PSVersion StartupScript RunAsUser Permission NetTechs Administrator NetTechs Administrator Pentru a vă conecta la un punct final personalizat, utilizați Invoke-Command sau Enter-PSSession, furnizând parametrul die -ConfigurationName pentru a specifica numele configurației morții Fără parametrul tiiat, vă veți conecta la punctul final PowerShell implicit al computerului, care este complet funcțional și (implicit) limitat la utilizarea de către administrator PS C:\> Enter-PSSession -ComputerName localhost -ConfigurationName nettechs Trebuie să rulați comanda tiiis într-o sesiune care rulează sub acreditările pentru un utilizator care aparține grupului NetTechs sau să utilizați parametrul -Credential pentru a specifica acreditările Odată conectat, puteți rula Get-Command pentru a verifica dacă numai comenzile dorite sunt vizibile în punctul final Dacă încercați să rulați o comandă neaprobată, cum ar fi Get - Service, veți primi o eroare, care este exact ceea ce ne-am dorit În mod normal, într-o sesiune la distanță, puteți folosi Exit pentru a părăsi sesiunea Dar într-o sesiune constrânsă tiiis este o comandă neaprobată În schimb, utilizați cmdletul Exit-PSSession Creați un utilizator local nou, numit TestMan, pe computer Asigurați-vă că atribuiți o parolă pentru contul murit Nu plasați utilizatorul în niciun grup de utilizatori sau în grupul de utilizatori implicit Apoi, creați un punct final constrâns pe computer Denumiți punctul final ConstrainTest Proiectați-l pentru a include numai modulul SmbShare și pentru a face vizibilă doar comanda Get-SmbShare (în plus față de un mic set de bază de cmdlet-uri precum Exit-PSSession, Select-Object și așa mai departe) După crearea configurației sesiunii , înregistrați punctul final Configurați punctul final pentru a permite numai TestMan să se conecteze (cu permisiuni de citire și executare) și configurați-l să ruleze toate comenzile ca cont de administrator local Asigurați-vă că furnizați parola corectă pentru administrator când vi se solicită Utilizați Enter-PSSession pentru a vă conecta la punctul final constrâns Când faceți acest lucru, utilizați parametrul -Credential pentru a specifica contul TestMan și furnizați parola corespunzătoare atunci când vi se solicită Asigurați-vă că puteți rula Get-SmbShare, dar nu orice altă comandă (sucii ca Get-SmbShareAccess) Bun venit la final! Ei bine, sfârșitul cărții - acesta este doar începutul carierei tale ca producător de instrumente PowerShell! La începutul cărții diis, am definit fabricarea de instrumente ca un al doilea tip de public PowerShell Acum faci parte din acel public; nu mai sunteți constrâns să utilizați instrumentele și comenzile oferite de alții, ci puteți combina diose pentru a vă crea propriile instrumente specifice sarcinii Indiferent dacă acestea sunt instrumente pe care le veți folosi pe cont propriu sau cele pe care le veți delega altor utilizatori mai puțin tehnici sau mai puțin privilegiați, acum sunteți în situația de a folosi cochilia pentru a automatiza sarcinile în mediul dumneavoastră Ce urmeaza? Al treilea public PowerShell – după utilizatorii de instrumente și producătorii de instrumente – sunt dezvoltatorii Aceștia sunt oameni care folosesc Visual Studio pentru a dezvolta aplicații care găzduiesc PowerShell și își valorifică puterile sau care creează instrumente mai complexe prin programarea în limbajul G#, Visual Basic sau anodier NET Framework Sincer, ne aflăm că de obicei putem obține aproape orice lucru de care avem nevoie folosind tehnicile de matriță pe care le-am prezentat în această carte Vrem să reiterăm o moarte din introducerea cărții: scopul nostru nu a fost să vă oferim o referință cuprinzătoare În schimb, am vrut să oferim un tutorial despre tehnicile de bază de fabricare a sculelor și asta este ceea ce am făcut Aproape tot ceea ce v-am arătat poate fi extins, ajustat și extins pentru a face mai mult și pentru a îndeplini scenarii specifice De exemplu, există o mulțime de alte operațiuni pe care le puteți face cu parametrii funcției avansați, mai multe puteți face cu vizualizări personalizate, o mulțime de altele pe care le puteți face cu fluxul de lucru și așa mai departe Vă vom lăsa la latitudinea dvs să cercetați aceste capacități suplimentare; Acum că aveți elementele de bază ale muștelor sub centură, adoptarea unor tehnici suplimentare ar trebui să fie destul de ușor Probabil că aveți deja scripturi PowerShell sau VBScript care ar putea beneficia de o transformare într-un instrument reutilizabil Sau dacă căutați câteva sugestii, vedeți dacă puteți dezvolta un instrument PowerShell pentru următoarele sarcini: Obțineți vârsta parolei a contului de administrator local de pe un computer la distanță Creați un instrument de raportare a unităților diat vă arată utilizarea unităților pe unitățile unui server Creați un instrument pentru a face copii de rezervă și pentru a șterge jurnalele de evenimente de pe computerele de la distanță Creați un instrument pentru a afișa utilizarea fișierelor de către proprietar pentru un anumit folder pe un anumit computer Creați un instrument pentru a afișa timpul de funcționare și ultima pornire pentru un grup de servere critice Încercați să dezvoltați un flux de lucru PowerShell, care să configureze mai multe servicii, să creeze o structură de foldere, să copieze unele fișiere și să creeze un nou cont de administrator local Creați un instrument pentru a interoga un computer pentru Servicii care rulează sub un cont local sau de domeniu Creați un instrument pentru a interoga un computer pentru toate certificatele expirate Rețineți că unele dintre ele ar putea beneficia chiar de un tratament GUI Cel mai bun sfat al nostru este să aprofundați Vino cu o idee pentru un instrument pe care îl poți folosi în propriul tău mediu și începe să-l scrii Probabil că veți rămâne blocat la un moment dat și sunteți binevenit să săriți pentru a ne posta o întrebare (boții dintre noi răspundem la întrebări) tions tiiere) Vom face tot posibilul să ajutăm Veți găsi alte expertize de actualitate la ID , astfel încât veți putea obține ajutor pentru subiecte specifice domeniului, cum ar fi IIS, SQL Server, SharePoint, Windows, Exchange și multe altele Mai presus de toate, nu întârzia Ar trebui să aveți încă în minte o mulțime de materiale proaspete din această carte, iar timpul să îl folosiți este acum Desigur, puteți oricând să răsfoiți paginile acestei cărți pentru a vă reîmprospăta memoria Vă vom avertiza puțin despre acest lucru: țineți cont de faptul că, în multe capitole, am furnizat Scripturi care aveau de fapt erori, așa că am putea trece peste acestea și le putem remedia Asigurați-vă că nu vă referiți la un script eronat! Vă vom oferi, de asemenea, o recomandare părtinitoare: Obțineți o versiune PowerShell în profunzime: un ghid al administratorului, pe care l-am scris împreună cu colegul MVP Richard Siddaway Este destinat mai mult ca o referință pe termen lung decât această carte (care este menită ca un tutorial) și acoperă aproape tot ceea ce ați putea avea nevoie să faceți în PowerShell Mult noroc! În capitolele - , v-am arătat cum să construiți o interfață grafică de utilizator (GUI) ca parte a unui script PowerShell Am ales să folosim tehnologiile WinForms și am folosit intens un instrument numit PowerShell Studio (fost PrimalForms), vândut de SAPIEN Technologies ( http://sapien com ) În această anexă, dorim să explicăm pe scurt unele dintre aceste decizii mai detaliat Sincer, există foarte puțină tehnologie asociată cu diferite decizii – sunt mai practice și mai politice – motiv pentru care am inclus această discuție într-o anexă, așa că nu a trebuit să întrerupem narațiunea principală a cărții A trebuit să alegem între două moduri distincte de a construi interfața grafică: Windows Forms, pe care oamenii le numesc WinForms, sau Windows Presentation Foundation, care se numește de obicei WPF WinForms este o tehnologie mai veche, datând din prima versiune a NET Framework Utilizează caracterul prompt Call-MainF orm pff functia Funcția Call-Results pff , metoda CanPingO , , Catch block , cd $pshome CenterScreen Change event Change () method - check boxes - Checked property - Checkpoint-Workflow comanda clase, în documentația NET Framework pentru instanțierea - - prezentare generală - Metoda Clear() Metoda ClearSelection() CLI (interfață de linie de comandă) Faceți clic pe evenimentul - , CloudShare com [ CmdletBinding () ] atributul , , , - , codificare culori - SColor variabilă anteturi de coloană, eliminând ComboBox control valori separate prin virgulă Consultați interfața de linie de comandă CSV Consultați comenzile CLI crearea de scripturi din - prezentare generală - parametri pentru - ajutor bazat pe comentarii - operatori de comparație - compatibilitate $computer variabilă , - coloana ComputerName ComputerName parametru - Proprietatea - , , , - ComputerName , , , , , variabilă $ComputerName , , , , $ComputerName Text proprietate - ComputerNameLabel pereche de etichete ConfigurationName parametrul Confirmați parametrul , , - , Confirmlmpact - , , $ConfirmPreference variabila - , - conectarea, la punctele finale constrânse la distanță ConnectionString proprietatea - , connectionTo proprietatea Font Consolas puncte finale constrânse la distanță - și arhitectura de la distanță conectarea la crearea definiției pentru - prezentare generală - înregistrarea - Continuați cuvântul cheie - Continuați valoarea Controale adăugarea la formularele WinForms cmdlet ConvertFrom-StringData - cmdlet ConvertTo-HTML , - , - , Metoda ConvertToDateTime () Declarație privind drepturile de autor Font Courier New Parametrul de acreditare - Parametrul $CssLTri Format CSV (valori separate prin virgulă) și ierarhii de obiecte - Date CSV Fișier CSV - - coduri de cultură caracterele paranteze , , , domeniul curent secțiunea de date, a funcțiilor , - $variabila de date acces la baza de date - funcții pentru modulul - pentru stabilirea mediului pentru - baze de date, creând control DataGridView Proprietatea DataSource folder -Parametrul de depanare -Comutatorul de depanare Sdeliug variabila depanare - adăugarea punctelor de întrerupere - adăugarea codului de urmărire - și așteptări proces pentru - tipuri de erori greșeli de tipar vizualizări - Secțiunea implicită definiții, pentru punctele finale constrânse la distanță - -Parametrul delimitator DependentServices - ghid de proiectare, pentru funcțiile - instrumente funcționale instrumente de intrare - instrumente de ieșire - strategii de proiectare, pentru fluxuri de lucru instrument de proiectare, modele GLT , pentru funcții avansate - dezvoltatori proprietate DeviceID Funcția Dir unități de disc $diskobjs array proprietatea - afișarea mesajelor, pentru erori - Proprietatea nume afișat Comanda Do-Something , Efectuați În timp ce construiește documentația , pentru clasele în NET Framework - caractere semn dolar controler de domeniu puncte sursă, pentru funcțiile - D o tNe tTyp es format, pslxml , ghilimele duble DriveType proprietate editori, pentru scripting Modul ridicat Else blocul , Blocul Elseif Expresia Elseif Declarații Elseif fișier format gol folder Activare-PS Rem o ting command , , , END bloc Ending property endpoints, la distanță - și la distanță arhitectura conectarea la crearea definiției pentru - de puncte finale, deplasarea la distanță (continuare) prezentare generală - înregistrarea - $entries variabila , enumerare, cu ForEach bucla - diagrama mediului , medii, setarea pentru acces la baza de date - -eq operator gestionarea erorilor , - $ErrorActionPreference variabila - afișarea mesajului pentru - în modulul SmbShare exemplu eroare de salvare în variabila - Construcții capcane - Încercați Prinde În cele din urmă construiește mesaje de eroare - Variabila $ErrorActionPreference - Parametrul ErrorFile , Parametrul ErrorLog , , , , - , Sl'Trorl ogvariable , erori manipularea variabilei - $ErrorActionPreference - codarea culorilor care afișează mesajul pentru - eroare de salvare în variabila - Constructii capcane - Încercați Prinde În cele din urmă construiește - salvarea variabilelor - -errorvariable -ErrorVariable parametru fișier ETS -EV parametru handlere de evenimente, WinForms rezultate jurnal de evenimente EventCountLabel $EventLogName $EventLog Name Selectați dl tem evenimente, WinForms variabilă $everything ok EXEMPLU secțiuni Proprietate ExampleProperty Buton Execute politici de execuție Cmdlet Exit-PSSession -Parametru ExpandProperty așteptări și depanare validarea funcție de export Export în fișierul Clipboard opțiunea Export-CliXML Export-CSV cmdlet , Export-HTML function - , , , - , - Export-ModuleMember comanda - Instalare rapidă Express Management Tools extensii, tip - adăugând la manifest - încărcare prezentare generală - ScriptMethod pentru - ScriptProperty pentru testarea - - antet suplimentar de coloană, eliminând Tasta F $False variabila Parametrul FilePath - Variabila $FilePath -Parametrul de filtru $filterl Sfîller forma finală declanșare, foldere WinForms FixedDialog , pentru modulele - Pentru constructele Parametrul de forță Pentru fiecare constructii - , , Pentru fiecare buclă , - , - Sintaxa ForEach cmdlet ForEach-Object - design formular aspect formular opțiuni de formular șabloane de formular format fișier, gol Format-Prezentare generală a comenzii personalizate - folosind cu imbricat obiecte - Comanda F ormat-MyPrettyDisplay Format-Tabel Fișiere format pslxml -Parametrul FormatsTo Process FormBorderStyle formulare adăugarea controalelor la trimiterea ieșirii la - Parametrul de fragment Clasa cadru - variabila $fred Proprietatea FreeSpace , , funcția cuvânt cheie , , eticheta , , - cod, pentru funcțiile - unelte funcționale funcții - , - acceptând intrarea conductei - și module rupte apelare din Scripturi - crearea din Scripturi - ghiduri de proiectare pentru - instrumente funcționale instrumente de intrare - instrumente de ieșire - pregătiri de proiectare - dot sourcing pentru - pentru acces la baza de date - cod funcțional pentru - globalizarea - beneficiile secțiunea de date pentru - prezentare generală - șiruri traduse pentru - ieșire pentru - parametri pentru - alias-uri pentru ajutor pentru - - obligatoriu - comutare parametru - validare - proxy - crearea de șabloane pentru funcțiile - (continuare) încărcare prezentare generală parametri pentru - șablon pentru - - ieșire verbose vs fluxurile de lucru - -ge operator Get-ADComputer Comanda Get-Cimlnstance , , , Get-Command -substantiv variabila Get-ComputerDetails functia Funcția Get-ComputerVolumelnfo Get-DetailedSystemlnfo funcția - cmdlet Get-EventLog Comanda Get-Job Comanda Get-Member , Get-MOLDdatabaseData - , - Comanda Get-MOLSystemlnfo - , , Get-MOLSystemlnfo -nume computer localhost Comanda Get-NetAdapter Get-OSInfo -computername localhost Funcția Get-OSInfo - , , Comanda Get-Process Get-RemoteSmbShare funcția - Comanda Get-Service , , , , Funcția Get-ServiceData Comanda Get-SmbShare Comanda Get-SmbShareAccess Comanda Get-Systemlnfo , , - , , Funcția Get-Systemlnfo , , , Comanda Get-Verb Comanda Get-WmiObject , - , - GetHashCode() metoda , , Metoda GetHostEntryO Metoda GetType() , , , , domenii globale - variabile globale $global events variabila $global logname variabila Global psdl - Global psml - , globalizare, a functiilor - beneficiile secțiunea de date pentru - prezentare generală - șiruri traduse pentru - Globals psl $go ahead variabilă Google Translate GPO (obiect Politică de grup) interfață grafică cu utilizatorul Vezi ( ' $GREAT variabilă grile Obiect Politica de grup Controale SccGPO GroupBox - -operatorul gt Instrumente Gl' I (interfață grafică utilizator) - clicuri pe butoane - casete de selectare - crearea Gl' I manual - folosind PowerShell Studio - creând Gl' I pentru, scoaterea la - casetele de listă - denumirea obiectelor în butoanele radio - afișând casetele de text Gl'I - folosind cmdlet Out-GridView - WinForms, prezentare generală Instrumentul de proiectare GUI care gestionează erorile - Variabila $ErrorActionPreference - afișarea mesajului pentru eroarea de salvare - în variabila - Construcții capcane - Încercați Prinde În final construiește - tabelul hash ajutor , - - bazat pe comentarii pentru parametrii „id-Ti pentru exemplul de modul SmbShare Bazat pe XML - Instrument Editor de ajutor sistem de ajutor Fila Acasă -Parametru HostName Pagina HTML il n (internaţionalizare) Vezi globalizarea Prefixul IBM Id parametru ID proprietate ID SQLEXPRESS instanță idei, pentru instrumente Dacă constructul , - , Dacă cuvântul cheie if declarația , niveluri de impact, pentru efectuarea modificărilor - Import-CliXML Import-CSV Comanda Import-LocalizedData , - Comanda Import-Module Import-Module MOLTools Import-Modul PSWorkflow - în cuvântul cheie Șablon InfoPath Bloc InlineScript Comandă InlineScript modul de intrare parametri de intrare INTRARE secțiunea instrumente de introducere — intrare, pentru funcțiile - Parametrul InputObject Întrebați valoarea folderul de instalare metoda Insert() PowerShell clase de instanțiere în NET Cadru - formulare și controale operator de invocare Invoke-CimMethod - , Comanda de invocare-comandă Funcția Invoke-MOLDatabaseQuery - , - , Invoke-WmiMethod - isSQLServer proprietatea - , - -Cmdlet-uri Job cuvinte cheie Labei control $LabelEnterComputerName variabila limbi, coduri de cultură -le operator -ca operatorul $line total casetele de listă - Funcția de încărcare , Funcția Load-ComboBox , Se încarcă funcții proxy tip extensii vederi - Metoda LoadWithPartialName() $global:variabila Modulul LOBAppTools - Instalarea LocalDB localizare Proprietatea locației Proprietatea jurnalului Parametrul LogErrors , , , Variabila $LogErrors , eroare de logică constructe logice - Întrerupe cuvântul cheie în - Dacă constructele - Comutator construiește - discuri logice LogNameLabel $LogNameLabel Text Slogs variabila bucle constructe - Întrerupe cuvântul cheie în - Continuați cuvântul cheie în - Faceți În timp ce construiește Pentru constructele Pentru fiecare constructii - - Operatorul Metoda Main() efectuând modificări - -Confirmați parametrul -Whatlf parametru niveluri de impact pentru - Metoda ShouldProcess () - MAMLfile Formatul MAML parametri obligatorii, pentru funcțiile - manifest adăugarea extensiilor de tip la - pentru modulele - crearea manuală a instrumentelor GLTI - Coloana Producător Proprietatea producătorului Clasa matematică MaximizeBox mesaje, afișate pentru erori - Microsoft InfoPath , Microsoft VisualBasic VBMath clasa MiddleCenter MinimizeBox Model coloana Proprietatea modelului moduri, exemplu de testare a de module, SmbShare - crearea modulului proiectare pentru - erori de manipulare în ajutor pentru parametri pentru variabilă la nivel de modul module - cuprinsul - creând din scriptul - definit dosar pentru - pentru acces la baza de date manifest pentru - nume pentru - variabile pentru - Prefixul MOL MOL Сотри terSystemlnfo MOL Disklnfo MOL ServiceProcessInfo MOL Systemlnfo obiect , - MOLDatabase folder MOLDatabase modul MOLDatabase psml - , $MOLErrorLogPreference variabila - folderul MOLTools Modul MOLTools - , MOLTools format pslxml MOLTools psdl MOLTools psml , - , - , , MSDN Library $msgTable obiect msgTable variabilă mai multe computere, ca condiția prealabilă - Dosarul Documentele mele Numele parametrului , Nume proprietatea , , , , denumire Comenzi modulele - obiecte din GLT -ne operator obiecte imbricate sintaxa matricei pentru creând - enumerarea cu bucla ForEach - folosind comanda Format-Custom cu - folosind comanda Select-Object cu NET Framework - , , - clase în documentația pentru - instanțierea - prezentare generală - în PowerShell vs Visual Studio - metode statice în - folosind Reflection Modul NetAdapter Modul NetSecurity - Grup NetTechs , - Opțiune formular nou Buton Interogare nouă - Comanda New-Alias — Comanda New-ModuleManifest Comanda New-PSSession N ew-PSSessionConfiguration- Fișier - Comanda New-Variable , Metoda NewGuid() Fișier NewScript psl eroare de non-terminare - -operator notlike $numbers variabilă Variabila Solij ierarhii de obiecte - și format CSV - sintaxa matricei de obiecte imbricate pentru crearea - enumerarea cu bucla ForEach - utilizând Comanda Format-Custom cu - când se utilizează Select-Object cu com mand necesare - obiecte, ieșire - Baza de date ODBC -Off parametru $OKButton variabilă OKButton Opțiune parametru OSVersion coloana OSVersion proprietate Out-GridView cmdlet - Out-Null ieșire pentru funcţiile - pentru instrumentele GET, trimiterea la formularul - pentru obiectele de ieșire cmdlet Trace-Command - , tastați numele pentru - OUTPUT secțiunea instrumente de ieșire - Construcția paralelă paralelism, al fluxurilor de lucru - Metoda Param() , , atribute parametri bloc de parametri ajutor parametru, adăugând PARAMETER cuvânt cheie mod parametru atribut [Parameter()] , , parametrii pentru comenzile - pentru funcțiile - aliasuri pentru - ajutor pentru - obligatoriu - comutare parametru - validare - pentru funcțiile proxy - pentru modulul SmbShare exemplu pentru fluxuri de lucru parendieses - , partiții XML lipit, modificarea Path parameter , , PeakPageFile property Persist workflow activity persistente, în workflows intrare pipeline acceptarea în funcțiile - prezentare generală - depanare, cu cmdlet Trace- Command - Obiectul PIPELINE , pipeline și scripting - Playicon , Parametru $PostContent Comanda PowerShell - , - , - , - Consola PowerShell Instrumentul PowerShell Help Editor PowerShell ISE, as condiția prealabilă Spațiul de rulare PowerShell Script PowerShell PowerShell Studio , - PowerShell v , ca cerință prealabilă PowerShell, vs Visual Studio - Parametrul PreContent Parametrul PrependPath , cerinte preliminare - Privilegii de administrator - mai multe computere - PowerShell ISE PowerShell v SQLServer PrimalForms PROCES blocul , Clasa de proces , Proprietatea ProcessID Proprietatea ProcessName Proprietăți listă de proprietăți, WinForms $props variabila Fișierul Proxies psml , , funcții proxy - crearea de șabloane pentru - incarcare prezentare generală parametrii pentru - Extensia de nume de fișier PS $PSBoundParameters - , - PSBreakpoint $psCmdlet - , -PSComputerName parametrul , $PSComputerName variabila -PSCredential parametru SPSCullure variabilă , psdl file , - PSHTools module , , PSHTools format pslxml variabilă PSModulePath - , PSObject , -PSParameterCollection parametrul -Parametrul PSPersist -Parametrul PSPort -PSSessionOption parametrul $PSUICulture variabila , - -Parametrul PSUseSSL $PSVersionTaI>l eticheta - Eticheta XML șabloane pentru funcții avansate - pentru funcții proxy - erori de terminare excepții de terminare - , Diagrama mediului de testare , Cmdlet Test-Path test format pslxml Fișier Test psl Modul Test psml testare, extensii de tip - Cont TestMan casete de text - Proprietatea text , , Valoare text Proprietatea TextAlign Add-in-uri terță parte Proprietate ThreadCount Cod de aruncat - , Crearea de instrumente a definit - idei pentru Toolmaking Demo Tools psl file , scop de nivel superior ToStringO metoda , , , , Total coloană $totalbought variabilă $totalsold variabilă - Metoda ToLTpper cod de urmărire, depanare cu cmdlet-ul - Trace-Command - ieșire pentru - Coloana tranzacției - Proprietatea tranzacției șiruri de caractere traduse, pentru globalizarea funcțiilor - Construcții capcane - vizualizare arborescentă depanare, conductă intrare - ieșire pentru - cu Trace-Command cmdlet - Variabila $True Încercați Prinde În final construiește - Încercați{} să construiți extensii de tip - adăugând la manifest - încărcare prezentare generală - ScriptMethod pentru - ScriptProperty pentru testarea - - nume tip, pentru obiectele de ieșire - TypeName greșeli de tipar, depanare - LTAC (Cont LTser Control) caracter de subliniere erori neașteptate Update-FormatData LTpdate-Help command vl O mode v mode ValidateCount() method validating așteptări parametri - atribut de validare ValueFromPipelineByParameter- Atribut nume var variabilă , prefixe variabile variabile - pentru modulele - eroare de salvare în ieșirea verbose - , pentru funcţiile - -Parametrul -Comutator Eticheta - , - , , tag pereche vizualizări - și tastați numele pentru obiectele de ieșire - crearea - depanare - încărcare - prezentare generală - folosind - Proprietatea vizibilă -Cmdlet VisibleCmdlets -Funcția VisibleFunctions Visual Studio, vs PowerShell - Proprietatea VMSize Clasa de volum de mesaje de avertizare, adăugând protocolul Web Services for Management WWS-MAN WF (Workflow Foundation) -Parametrul Whatlf Variabila $WhatIfPreference Construcții Wliile Consultați Do While constructii -opțiune wildcard Win ComputerSystem clasa Win OperatingSystem clasa , , - , , Metoda Win Shutdown Instrumente de management Windows SccWMI Windows Presentation Foundation SccWPF Windows Remote Management Vezi WinRM Windows Workflow Foundation Windows, versiunea în limba engleză a Dosarul WindowsPowerShell WinForms WinRM (Windows Remote Management) WMI (Administrare Windows Instrumentație) , , Comanda WMI , Interogări WMI , , WMI Win Volume class $workflow:myvar Workflow Foundation &«Cuvânt cheie flux de lucru WF - $workflow scope identifier workflows - conceptul de activități în - proiectare exemplu de - prezentare generală - paralelism a - parametrii pentru starea persistentă la distanță cu - reluarea suspendarea vs funcții - WPF (Windows Presentation Foundation) Comanda Scriere-Depanare Instrucțiuni Write-Debug Comanda Write-Host Comanda Scriere-Ieșire , - Comanda Scriere-Verboză - Scriere-Avertisment $ Excepție Mesajul WS-MAN (Servicii web pentru administrare) , Variabila Sx Editor XML Fișier XML - , , , - , , Formate XML Etichete XML Ajutor bazat pe XML - # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Running the new script file Running the new script file Running C:\Tools ps! Running C:\Tools ps! Running C:\Tools ps! Running C:\Tools ps! Dot sourcing C:\Tools ps! and then running the Get-OSInfo function Dot sourcing C:\Tools ps! and then running the Get-OSInfo function Dot sourcing C:\Tools ps! and then running the Get-OSInfo function Dot sourcing C:\Tools ps! and then running the Get-OSInfo function Running Tools psl to define and test our function Running Tools psl to define and test our function Running Tools psl to define and test our function Running Tools psl to define and test our function # # # # # # # # # # # # # # # # # # Testing the new module Testing the new module Testing the new module Testing the new module Saving the MOLDatabase module Saving the MOLDatabase module # # # # # # # # # # # # # # Creating a new form for our project Creating a new form for our project # # # # # #